IBM Application Performance Management for IBM Worklight … · 2013-06-13 · IBM® Cloud and Smarter Infrastructure Application Performance Management for IBM Worklight mobile applications

IBM® Cloud and Smarter Infrastructure

Application Performance Management for IBM Worklight mobile applications

Document version 1.0

John GriffithLarry McWilliamsMark Weatherill Ren Fu MaQi Gang Zhu

© Copyright International Business Machines Corporation 2013. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Application Performance Management for IBM Worklight mobile apdddplApplication Performance Management for IBM Worklight mobile apps

CONTENTS

Contents.............................................................................................................................iii

List of Figures....................................................................................................................vi

List of Tables......................................................................................................................ix

Revision History..................................................................................................................x

1Introduction.......................................................................................................................1

2Use Case Scenarios.........................................................................................................2

2.1Use Case 1: Real-user monitoring....................................................................2

2.2Use Case 2: Synthetic transaction monitoring..................................................4

2.3Use Case 3: Resource monitoring....................................................................5

3Solution Environment Overview and Deployment.............................................................8

3.1Typical Worklight Environment..........................................................................8

3.2Phase 1: Real User Monitoring.........................................................................8

3.2.1Architectural Overview.....................................................................................9

3.2.2Real User Monitoring Component Deployment................................................9

3.3Phase 2: Synthetic Transaction Monitoring.....................................................10

3.3.1Architectural Overview...................................................................................10

3.3.2Synthetic Transaction Monitoring Component Deployment...........................12

3.4Phase 3: Resource Monitoring........................................................................12

3.4.1Architectural Overview...................................................................................13

3.4.2Resource Monitoring Component Deployment..............................................13

iii

Application Performance Management for IBM Worklight mobile applicationsdfsdfApplication Performance Management for IBM Worklight mobile apps

4Configuring Real User Monitoring...................................................................................15

4.1Defining a Worklight Application in the Application Management Configuration Editor...................................................................................................................15

4.2Configuring user and session tracking............................................................16

4.3Defining Worklight Transactions......................................................................17

4.4Create a monitoring profile..............................................................................19

4.5Defining client groups......................................................................................20

4.6Verifying WRT is capturing data using the console.........................................20

5Configuring Synthetic Transaction Monitoring................................................................22

5.1Installing the Worklight Application onto a test device.....................................22

5.2Configuring the test device to use the Rational Performance Tester proxy.....25

5.3Recording a script in Rational Performance Tester.........................................27

5.4Modifying the script for playback.....................................................................32

5.4.1Handling Worklight authentication realms......................................................32

5.4.2Organizing requests into high-level transactions steps..................................36

5.4.3Adding verification points...............................................................................36

5.5Uploading and scheduling robotic playback in ITCAM for Transactions..........38

6Using the Application Performance Management User Interface....................................40

6.1Configuring the data provider..........................................................................40

6.2Creating an application from a template..........................................................41

7Conclusion......................................................................................................................43

iv

Application Performance Management for IBM Worklight mobile apdddplApplication Performance Management for IBM Worklight mobile apps

Appendix A........................................................................................................................vi

Appendix B........................................................................................................................vii

v

Application Performance Management for IBM Worklight mobile appsApplication Performance Management for IBM Worklight mobile apps

LIST OF FIGURES

Figure 1: Application Dashboard.........................................................................................2

Figure 2: Client Dashboard.................................................................................................3

Figure 3: Transaction Dashboard.......................................................................................4

Figure 4: Transaction Status workspace.............................................................................5

Figure 5: Typical Worklight topology...................................................................................8

Figure 6: Real user monitoring using the Web Response Time agent................................9

Figure 7: Synthetic transaction monitoring using the Robotic Response Time agent........11

Figure 8: Recording synthetic transactions with Rational Performance Tester.................11

Figure 9: Resource monitoring using application and OS agents.....................................13

Figure 10: Creating an application in the AMCE...............................................................15

Figure 11: User and session tracking...............................................................................16

Figure 12: Creating a transaction......................................................................................18

Figure 13: Creating a Filter...............................................................................................19

Figure 14: Configuring reporting parameters....................................................................19

Figure 15: Creating WRT profile.......................................................................................19

Figure 16: Configuring agent distribution.........................................................................19

Figure 17: Android client group.........................................................................................20

Figure 18: Configuring reporting for client groups.............................................................20

Figure 19: Application Interactions workspace..................................................................21

Figure 20: Android Virtual Device Manager......................................................................22

Figure 21: Android Virtual Device Manager......................................................................23

Figure 22: Edit Android Virtual Device (AVD)...................................................................23

Figure 23: Launch.............................................................................................................24

Figure 24: AVD screen display.........................................................................................24

Figure 25: Android application panel................................................................................25

Figure 26: Settings...........................................................................................................25

Figure 27: Wireless & networks........................................................................................26

Figure 28: Wireless & networks........................................................................................26

Figure 29: Mobile network settings...................................................................................26

Figure 30: Access Point Names........................................................................................27

Figure 31: Edit access point.............................................................................................27

vi


Figure 32: Selecting an Unmanaged Application..............................................................28

Figure 33: Proxy Recorder Settings..................................................................................29

Figure 34: Application recording.......................................................................................29

Figure 35: Launch FlightTicket app...................................................................................30

Figure 36: Monitoring the recording..................................................................................31

Figure 37: Test contents...................................................................................................32

Figure 38: Authorization heading in the recording.............................................................33

Figure 39: Manually adding header..................................................................................33

Figure 40: Request headers contain the Authorization header.........................................33

Figure 41: Creating substitutions......................................................................................34

Figure 42: Creating substitutions......................................................................................34

Figure 43: Reference name..............................................................................................35

Figure 44: Checking substitution sites..............................................................................35

Figure 45: Post-substitution..............................................................................................35

Figure 46: Modified script.................................................................................................36

Figure 47: Switch to ITCAM perspective...........................................................................36

Figure 48: Adding verification points.................................................................................37

Figure 49: Running your script within RPT.......................................................................37

Figure 50: RPT test results...............................................................................................38

Figure 51: Robotic data in the TEP console......................................................................39

Figure 52: Connection Panel in TIP.................................................................................40

Figure 53: Connection Summary in TIP...........................................................................40

Figure 54: Provider Configuration in APM UI...................................................................40

Figure 55: Application Configuration Panel in APM UI......................................................41

Figure 56: Resource Dashboard......................................................................................42

vii


LIST OF TABLES

Table 1: Worklight authenticators.....................................................................................16

Table 2: Worklight login modules......................................................................................16

Table 3: Transaction definition for Adapter requests.........................................................17

Table 4: Transaction definition for Application API requests.............................................17

Table 5: Transaction definition for Logout.........................................................................17

viii


REVISION HISTORY

Date Version Revised By Comments

2013-06-06 1.0 MW Initial version

ix

Solution Environment Overview and Deployment

1 IntroductionThe intended audience for this solution paper is the application owner that needs the ability to manage the performance and availability of their mobile applications built on IBM Worklight. This solution utilizes a phased approach for installing and configuring IBM SmartCloud Application Performance Management 7.6.

In the first phase, real user monitoring is implemented using the Web Response Time agent. With real-user monitoring, you get visibility into the performance of mobile clients connecting to the Worklight server. You can differentiate mobile from desktop clients and track the performance of individual users.

In the second phase, synthetic transaction monitoring is implemented using the Robotic Response Time agent. With synthetic transaction monitoring, you are actively testing whether key transactions are available and performing. You can identify issues before they impact your end-users.

In the final phase, resource monitoring is implemented using OS and Applications agents. With resource monitoring, you gain visibility into the infrastructure which supports your applications. This visibility is essential to quickly diagnose issues which are impacting the end-user experience.

The solution paper contains best practices for the following Worklight topics:

• Granular monitoring of Worklight adapter procedures

• Tracking logged in users for different types of Worklight login and authenticator modules

• Distinguishing mobile clients according to operating system (E.g., iOS vs Android vs desktop)

• Recording synthetic HTTP transactions using apps running on real or simulated devices

• Modifying synthetic recordings to handle Worklight authentication realms

This solution demonstrates highly responsive and intuitive dashboards for managing the performance and availability of mobile applications. The dashboards are rapidly composed from out-of-the-box templates.

This solution and the use case scenarios, which are described in the next section, were tested and proven in our IBM® lab.

1


2 Use Case ScenariosIn this section we describe three use cases that use this solution’s capabilities to manage performance and availability in a Worklight application.

The scenarios are demonstrated using the FlightTicket sample application provided with Worklight 5.0.6. The FlightTicket sample app is a business-to-consumer (B2C) example that demonstrates different capabilities of a hybrid application in an end-to-end scenario. The scenario covers an individual who is making and managing a flight booking.

The FlightTicket sample application is available in the Worklight information center:

Getting started tutorials and samples

2.1 Use Case 1: Real-user monitoring A Worklight application owner needs to manage the performance of the adapters used by his application as a slow down in an adapter will directly impact the user experience. He uses real-user monitoring to monitor the response time for each adapter procedure.

The Worklight application owner receives a trouble ticket stating that the Flight Ticket application is performing slowly at times. He uses the SmartCloud APM UI to investigate the issue. The Application Overview shows his list of applications and reveals that the FlightTicket application is in a warning state.

Figure 1: Application Dashboard

http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m6/topic/com.ibm.worklight.help.doc/start/c_gettingstarted.html


He navigates to the Client Dashboard which reveals that both iOS and Android users are experience slow transactions.

Figure 2: Client Dashboard

He navigates to the Transactions Dashboard which shows the performance of each adapter procedure.

3


Figure 3: Transaction Dashboard

From this view he can see that the createOrder and updateOrder procedures are taking over 6 seconds, which exceeds the SLA. This directly impacts the end-users that are booking flights and will result in user frustration and possibly lost sales. He transfers the ticket to a Worklight SME to resolve the performance issue with the adapter.

2.2 Use Case 2: Synthetic transaction monitoring A Worklight application owner needs to actively test the key functions of his application to ensure they are available 24/7. He uses synthetic transaction monitoring to playback test scripts that exercise the key functions of the application. With this approach, issues can be identified and corrected before end-users are affected.

An operator receives a trouble ticket because the script for booking a flight is failing. He launches the Tivoli Enterprise Portal to dive into the issue.

The Transaction Status workspace reveals that all steps of the transaction are failing with an incorrect HTTP return code.


Figure 4: Transaction Status workspace

He has identified a critical issue with the Worklight server which is impacting users. He transfers the ticket to a WebSphere SME to restore the server.

2.3 Use Case 3: Resource monitoring

Resource monitoring can help the Worklight application owner determine whether the infrastructure is impacting application performance.

The application owner can use the Application Overview to identify applications that are encounter resource issues.

5


Figure 4: Application Overview

He suspects that the resource issue might be affecting the application performance, so he clicks the resource link, which opens the Resource Dashboard. He notices the status for one of the application servers is critical with a high response time.


Figure 5: Resource Dashboard

The owner clicks on the offending WebSphere application server for drill-down into the dashboard.

Figure 6: WAS Details Dashboard

He notices one of the data sources is unavailable. He navigates back to the resource summary and drills down into the database dashboard. He notices the SYSCATSPACE tablespace is close to being full as shown in the following figure:

Figure 7: DB2 Detail Dashboard

He confirms with the DB administrator that the database needs servicing to restore access performance. After servicing, the FlightTicket application performance is restored and in good health.

7


3 Solution Environment Overview and Deployment This section provides an overview of the software components, architecture and procedures to deploy the solution into an existing SmartCloud APM infrastructure to achieve the results in the use case scenarios.

The deployment is broken down into three phases:

Phase 1: Real user monitoring using the Web Response Time agent

Phase 2: Synthetic transaction monitoring using the Robotic Response Time agent

Phase 3: Resource monitoring using the ITCAM for Applications agents

3.1 Typical Worklight EnvironmentThe Worklight server can be installed in different network configurations, which might include several DMZ layers, reverse proxies, NAT devices, firewalls, high availability components such as load balancers, IP sprayers, clustering, and alike. The figure below shows a typical Worklight topology which was used in our testing of the solution. Most components were installed as Red Hat Enterprise Linux on 64-bit systems and Windows 2008 R2 64-bit.

Figure 5: Typical Worklight topology.

3.2 Phase 1: Real User MonitoringReal user monitoring is used to monitor requests to the HTTP interface of the Worklight server. This captures the end-user response time for Worklight adapters and other requests such as app initialization and authentication.

This section describes the architectural overview and deployment procedures for the real user monitoring capability of this solution.

IBM HTTP Server

Worklight Cluster

Legacy Backend 2

Load Balancer

Worklight database

Mobile Clients

Legacy Backend 1


3.2.1 Architectural Overview

The figure below shows where monitoring agents are placed in the Worklight environment. The items in orange are the components needed to enable the real user monitoring capability.

Figure 6: Real user monitoring using the Web Response Time agent.

The figure shows an agent-less setup for the Web Response Time (WRT) agent, which is installed on a remote system to monitor HTTP traffic. For agent-less monitoring, the WRT agent should be on the same network switch as the load balancer for the HTTP server. The switch must be configured with port mirroring.

3.2.2 Real User Monitoring Component Deployment

In this section, we summarize the basic installation for this capability. If applicable, special notes or nuances are explained.

ITCAM for Transactions: Application Management Console agent

The Application Management Console (AMC) agent is required when other ITCAM for Transactions agents are installed. The AMC agent manages and distributes monitoring profiles, client groupings and transaction recordings.

For more details on product version and maintenance levels, refer to the ITCAM for Transactions entry in Appendix A.

For more details on installing and configuring the AMC agent, refer to the following sections from the SmartCloud APM information center:

9

IBM HTTP Server

Worklight Cluster

Legacy Backend 2

Load Balancer

Worklight database

Mobile Clients

Legacy Backend 1

SmartCloud APM infrastructure

Worklight Environment

Application Management

Console agent

Web Response Time agent


Installing Response Time monitoring agents and related software

Configuring Application Management Console

ITCAM for Transactions: Web Response Time agent

For agent-less monitoring using WRT, you must have a single dedicated system for the WRT agent. We recommend using the agent-less configuration if you desire to off-load the analysis overhead from the web server.


For more details on installing and configuring the WRT agent, refer to the following sections from the SmartCloud APM information center:


Configuring Web Response Time

3.3 Phase 2: Synthetic Transaction Monitoring

Synthetic transaction monitoring is used to actively test the key functions of an application. SmartCloud APM includes Rational Performance Tester for recording monitoring scripts based upon the HTTP traffic between the client and server. The monitoring scripts are periodically replayed using the Robotic Response Time agent which reports on the performance and availability.

This section describes the architectural overview and deployment procedures to enable the synthetic transaction monitoring capability of this solution.


The figure below introduces the synthetic transaction monitoring capability with the Robotic Response Time agent that you use play back key transactions of your application. Robotic Response Time agents can be deployed to different geographic locations in order to distinguish client and server issues.

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamt.doc_7.3.0.1/rt/Install_Guide/wrt_config.html

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamt.doc_7.3.0.1/rt/Install_Guide/installation.html

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamt.doc_7.3.0.1/rt/Install_Guide/amc_config_oview.html



Figure 7: Synthetic transaction monitoring using the Robotic Response Time agent.

The synthetic transaction test scripts are recorded using Rational Performance Tester. The figure below shows how Rational Performance Tester is used as a HTTP proxy to record traffic between a mobile device and the Worklight server. The test script is exported to the Application Management Console agent where it can then be distributed to Robotic Response Time agents for playback.

Figure 8: Recording synthetic transactions with Rational Performance Tester.

11

IBM HTTP Server

Worklight Cluster

Legacy Backend 2

Load Balancer

Worklight database

Mobile Clients

Legacy Backend 1




Console agent


Robotic Response Time agent

Real or virtual devices


Console agent

Rational Performance

Tester Load

Balancer


3.3.2 Synthetic Transaction Monitoring Component Deployment


ITCAM for Transactions: Robotic Response Time agent

You can use the Robotic Response Time (RRT) agent to play back your recorded Worklight transactions. The RRT agent can be installed along with the AMC agent. The RRT agent can be installed in different locations where clients are accessing your applications.


For more details on installing and configuring the RRT agent, refer to the following sections from the SmartCloud APM information center:


Configuring Robotic Response Time

Rational Performance Tester

To record synthetic transactions, install Rational Performance Tester (RPT) on either a developer's workstation or on a dedicated system. In our tests, we installed RPT on Windows 2008 R2 64-bit.

The ITCAM for Transaction Integration Support Export Plugin is installed into RPT. This plugin allows you to export test scripts to the Application Management Console agent.


For more details on installing RPT, refer to the following sections from the Rational information center:

Installing Rational Performance Tester

For more details on installing the ITCAM for Transactions Integration Support, refer to the following sections from the SmartCloud APM information center:

Installing integration support for Rational Performance Tester

3.4 Phase 3: Resource MonitoringResource monitoring gives visibility into the performance and availability of the infrastructure which supports Worklight applications.

This section describes the architectural overview and deployment procedures to enable the resource monitoring capability of this solution.

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamt.doc_7.3.0.1/rt/Install_Guide/install_rpt.html

http://pic.dhe.ibm.com/infocenter/rpthelp/v8r3m0/index.jsp?topic=%2Fcom.ibm.rational.test.lt.install.doc%2Ftopics%2Ft_preinst_prep_launch.html

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamt.doc_7.3.0.1/rt/Install_Guide/rrt_config.html




Resource monitoring can be phased in as shown in the figure below. It is important to note that the resource monitoring can be added at any phase of this solution. Resource agents can include OS agents to monitor the underlying operating system where the application server resides, database agents to monitor the application server data repository, HTTP agents to monitor the web server, and WebSphere agents to monitor the Worklight server.

Figure 9: Resource monitoring using application and OS agents

3.4.2 Resource Monitoring Component Deployment


ITM: Operating system agent

OS agents can be installed on the Worklight infrastructure. Remote OS monitors could be used instead, though they do not provide as much detail as agent-based monitors. In our tests, we installed Linux OS agents on all of our servers in our test environment.

For more details on product version and maintenance levels, refer to the IBM Tivoli Monitoring entry in Appendix A.

For more details on installing the OS agent, refer to the following sections from the SmartCloud APM information center:

13

IBM HTTP Server

Worklight Cluster

Legacy Backend 2

Load Balancer

Worklight database

Mobile Clients

Legacy Backend 1




Console agent


Robotic Response Time agent

HTTP agent

DB2 agent

OS agent

WebSphere agent

OS agent

OS agent


Installing monitoring agents

ITCAM for Applications: Database agent

The ITCAM for Applications DB2 or Oracle agent is installed to monitor the Worklight database and other databases used by SQL adapters. In our environment, we installed the DB2 agent to monitor the Worklight data sources.

For more details on product version and maintenance levels, refer to the ITCAM for Applications entry in Appendix A.

For more details on installing the DB2 agent, refer to the following sections from the SmartCloud APM information center:

Installation and Configuration

ITCAM for Applications: Agent for WebSphere Applications

The ITCAM Agent for WebSphere Applications is installed on each WebSphere node to provide the deepest and most fine grained monitoring of each server on that node. In the environment, the WebSphere agent was installed on both nodes.


For more details on installing the WebSphere agent, refer to the following sections from the SmartCloud APM information center:

Agent for WebSphere Applications Installation and Configuration Guide

ITCAM for Applications: Agent for HTTP Servers

The ITCAM Agent for HTTP Servers is installed on each HTTP server in your Worklight environment. In the test environment, the HTTP agent was installed on our single node running IBM HTTP Server.


For more details on installing the HTTP agent, refer to the following sections from the SmartCloud APM information center:

Agent for HTTP Servers

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamfapps_ad.doc_72/planning_an_installation/HTTPServersAgent.html

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamfapps_ad.doc_72/was_agent_install_dist.html

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcama.doc_7.1/db2agent71_user18.htm?path=1_6_4_4_3#config

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itm.doc_6.2.3fp1/itm623FP1_install198.htm?path=1_6_6_0_3_0_6_3_3#ma_install


4 Configuring Real User MonitoringIn this section, you configure the Web Response Time (WRT) agent to enable real user monitoring of your Worklight applications. This consists of the following high-level steps:

1 Defining a Worklight application in the Application Management Configuration Editor

2 Configuring user and session tracking

3 Defining Worklight transactions

4 Creating a monitoring profile

5 Defining client groups

6 Verifying data collection

4.1 Defining a Worklight Application in the Application Management Configuration EditorFrom within the Tivoli Enterprise Portal, launch the Application Management Configuration Editor (AMCE) to create a definition for your Worklight application. For more details on using the AMCE refer to the following section of the SmartCloud APM information center:

Using the Application Management Configuration Editor

For each Worklight application, create an application (e.g. “FlightTicket”) as shown in the figure below:

Figure 10: Creating an application in the AMCE

15

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamt.doc_7.3.0.1/rt/AMC_Editor/AMCE_intro.html


4.2 Configuring user and session trackingConfigure the application's user and session definitions to capture who is visiting your mobile application.

Worklight applications running on WebSphere use the default session cookie called “JSESSIONID”. Under the Session tab, add an HTTP cookie type with key name of JSESSIONID:

Figure 11: User and session tracking

Under the Users tab, define how to identify a user from the HTTP requests. The specific setting will depend on the type of authenticator and login module used in the Worklight application.

User identity can be extracted from the following Worklight authenticators:

Table 1: Worklight authenticators

Authenticator Type Key name

BasicAuthenticator Basic authorization -

FormBasedAuthenticator HTTP form post data j_username

User identity can be extracted from the following Worklight login modules:

Table 2: Worklight login modules

Login Module Type Key name

HeaderLoginModule HTTP header <user-name-header>

Note: The FlightTicket application uses Adapter authentication in which the username and password are passed to the server in a JSON payload. The Web Response Time agent is unable to extract the username for this type of authenticator. The implication for the FlightTicket application is that the Web Response Time agent won’t show per-user metrics.


4.3 Defining Worklight TransactionsWorklight applications make requests to the HTTP interface of the Worklight server. For more details on this interface, refer to the Worklight information center:

HTTP Interface of the production server

In the AMCE, you want to create transaction definitions so that requests to the Worklight server HTTP interface are presented in a meaningful, actionable way. The following transaction definitions will ensure that requests to the server are reported consistently with the Worklight documentation

Table 3: Transaction definition for Adapter requests

Transaction Name Adapter requests

Transaction Type HTTP/S

Filter

Name Value

URLFile Query

URLPath *apps/services/api/FlightTicket/*

Reporting

Name Value

Application name Flight Ticket

Transaction name query/$HTTP.POST:adapter$/$HTTP.POST:procedure$

Server name $IPDestinationAddress$:$DestinationPort$

Table 4: Transaction definition for Application API requests

Transaction Name Application API requests


FilterName Value


Reporting

Name Value


Transaction name $URLFile$


Table 5: Transaction definition for Logout

17

http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m6/topic/com.ibm.worklight.help.doc/admin/r_http_interface_of_the_prod_server.html


Transaction Name Logout


Logoff True

Filter

Name Value

URLFile Logout


Reporting

Name Value


Transaction name query/$HTTP.POST:adapter$/$HTTP.POST:procedure$


The following step-by-step instructions walk through the process of creating a transaction definition.

Figure 12: Creating a transaction

Now configure the filter definitions for the transaction. Create one filter called “URLFile” based on the fact that all Worklight adapter invocation requests end with “query.” Then create another filter where all requests for the Worklight applications include the URL segment “apps/services/api/FlightTicket”:


Figure 13: Creating a Filter

The name of the Worklight adapter and procedure that are being invoked are contained in the HTTP POST parameters. Configure the reporting parameters as shown then save the transaction:

Figure 14: Configuring reporting parameters

4.4 Create a monitoring profileCreate a WRT profile and start our Worklight application transaction definitions.

Figure 15: Creating WRT profile

The profile is distributed to the WRT agents as shown below:

Figure 16: Configuring agent distribution

19


4.5 Defining client groupsAs an application owner, you need to be able to identify client platforms which are experiencing issues. The capability for defining client groups can be used to model groups of users from specific locations, or organizations, or in the case of a business-to-consumer application, such as this one, to model the client platform running the application. This is achieved by filtering clients according to the UserAgent HTTP header which is sent in every HTTP request.

In the Application Management Console, define your clients in the client view as shown in the figure below. This example shows an Android client keying off the BrowserDescription with value *Android*.

Figure 17: Android client group

In a test environment, it can be useful to append a dynamic identifier such as the IP address in the client name. This can help to validate that groups are being allocated correctly according to platform. However in a production environment this will create a very large volume of data and should be avoided.

Figure 18: Configuring reporting for client groups

4.6 Verifying WRT is capturing data using the consoleOnce you've set-up the various WRT configurations described above, you will see workspaces like the Application Interactions shown below. In this example, we can see the client, transactions and servers.


Figure 19: Application Interactions workspace

21


5 Configuring Synthetic Transaction MonitoringIn this section, you record synthetic transactions with Rational Performance Tester (RPT) and schedule for playback in the Robotic Response Time (RRT) agent.

This section goes through the following steps:

1 Installing the Worklight application onto a test device

2 Configuring the test device to use the Rational Performance Tester proxy

3 Recording a transaction in Rational Performance Tester

4 Modify the script for playback

5 Uploading and scheduling script playback in ITCAM for Transactions

5.1 Installing the Worklight Application onto a test deviceIn this example, we run the app on an Android Virtual Device (AVD). Similar steps apply when using a physical Android device or an iOS device.

First, you need to create an Android Virtual Device to run your mobile application.

In the Worklight Studio workbench, open the Android Virtual Device Manager.

Figure 20: Android Virtual Device Manager

From the Android Virtual Devices tab, select New:


Figure 21: Android Virtual Device Manager

Fill in your AVD Name, Target (the desired Android platform) and SD Card, and then click OK to save it:

Figure 22: Edit Android Virtual Device (AVD)

From the Android Virtual Device Manager click Start to launch the AVD:

23


Figure 23: Launch

This will launch the AVD screen display:

Figure 24: AVD screen display

Open the browser in the AVD to install the native application from your published application site.

E.g., http://<worklight-server>:9080/appcenterconsole/installers.html

After installation, you will see the icon in the Apps Panel:


Figure 25: Android application panel

5.2 Configuring the test device to use the Rational Performance Tester proxy

After your application has been installed on the mobile device, you need to change the proxy settings so that the HTTP requests sent by the application will be served through the embedded Rational Performance Tester HTTP recording proxy.

From Setting->Wireless and Networks->More->Mobile Network->Access Point Names->T-Mobile US:

Figure 26: Settings

25


Figure 27: Wireless & networks

Figure 28: Wireless & networks

Figure 29: Mobile network settings


Figure 30: Access Point Names

Modify the proxy settings to use the system where RPT 8.3 is installed.

E.g., if RPT 8.3 is installed on 9.123.0.1, the use the following settings:

Figure 31: Edit access point

5.3 Recording a script in Rational Performance TesterIn Rational Performance Tester, create a new Performance Test project (e.g., “FlightTicket”), then create an HTTP test recording script (e.g., “Book Flights”) under this project. In the Client Application step, choose Unmanaged Application:

27


Figure 32: Selecting an Unmanaged Application

Select the HTTP Proxy type, and configure the proxy port. Ensure the port number matches what was used in the proxy settings on the mobile device.


Figure 33: Proxy Recorder Settings

Click Next, check the accept box, and click Finish. When the recorder starts, RPT will record any HTTP traffic through the port 1080.

Figure 34: Application recording

29


On your test device, ensure you start recording before loading the application as otherwise you can miss important initialization traffic.

Figure 35: Launch FlightTicket app

Within your application on the device, execute some key transactions you wish to monitor. In RPT, you will notice the KBytes counter increasing in the Recorder Control table as the app issues HTTP requests to the Worklight server.


Figure 36: Monitoring the recording

After you have manually completed all of the transactions that you want to record from your mobile client, you can stop the recorder by clicking on the Stop button in the Recorder Control tab. The recorded script will be shown in the Test Contents window:

31


Figure 37: Test contents

5.4 Modifying the script for playback

After recording your transaction script, you need to perform some manual modification in Rational Performance Tester. This is tackled in the following steps:

1 Handling Worklight authentication realms

2 Organizing requests into high-level transaction steps

3 Adding verification points

5.4.1 Handling Worklight authentication realms

All Worklight applications are protected by two default authentication realms:

• wl_antiXSRFRealm

• wl_deviceNoProvisioningRealm (hybrid/native smartphone environments only)

The first request to the Worklight server will return HTTP 401 Unauthorized. The content of the response contains values which must be substituted into HTTP headers in subsequent requests.

The second request to the Worklight server needs to contain an “Authorization” HTTP header. This header is not recognized by RPT and needs to be manually copied from the recording into the test script.


Open up the recording file and navigate to “Proxy sends to Connection 2”. You can see on the right hand side that it captured a value for "Authorization" as shown here:

Figure 38: Authorization heading in the recording

Manually add that header to the second request in your test since RPT dropped it from the playback:

Figure 39: Manually adding header

Ensure that the header now appears in the Request Headers.

Figure 40: Request headers contain the Authorization header

33


Now that you have all of the right headers in your script, you need to ensure the script sends values which are correctly substituted based upon what is returned by the server. When you visit a Worklight mobile application, the server can generate two unique identifiers;

• WL_Instance_ID – this value needs to be passed as a HTTP header in all of the following requests.

• Token – this value needs to passed in the Authorization HTTP header

In the test's response body, find the value of the unique identifier – WL_Instance_ID:

Figure 41: Creating substitutions

Highlight it and right click to create a reference as shown below:

Figure 42: Creating substitutions

Then name this reference as shown:


Figure 43: Reference name

Choose Select All and click Substitute Checked as shown:

Figure 44: Checking substitution sites

You will see the new substitution will be changed to different color:

Figure 45: Post-substitution

Create a substitution for token using the same approach.

35


5.4.2 Organizing requests into high-level transactions steps

Your recording may contain many heartbeat requests which aren’t needed during playback. You can delete most of these, though be careful not to delete the initial two requests to the Worklight server as these implement the authentication challenge.

Since RPT only observes the HTTP traffic, it is unable to provide meaningful names for the transaction steps in the recording. It is typically useful to create transaction steps for each adapter invocation.

The figure below shows an example of a recorded script broken up into descriptive transactions:

Figure 46: Modified script

5.4.3 Adding verification points

Verification points in the script ensure that the server is returning the expected data. They are needed to accurately monitor the availability of your application.

After you installed ITCAM for Transaction Integration Support, you will see one new perspective. Switch to this perspective to add verification points to your script, especially for Return Code:

Figure 47: Switch to ITCAM perspective


Figure 48: Adding verification points

After that, test your script by running it within RPT:

Figure 49: Running your script within RPT

The results should look like this:

37


Figure 50: RPT test results

5.5 Uploading and scheduling robotic playback in ITCAM for Transactions

Now you are ready to upload your scripts and schedule playback in ITCAM for Transactions.

For details on uploading and scheduling script playback for ITCAM for Transactions, please refer to the following sections from the SmartCloud APM information center:

Exporting Rational Performance Tester scripts

Procedure: Selecting transactions for a profile

Note: When uploading your test scripts, set the same application name that you used with the Web Response Time agent. E.g., “FlightTicket”. This will ensure consistent presentation in the TEP workspaces and APM UI dashboards.

Verify that you have robotic playback data in the workspaces in the TEP console as shown in the figure below:

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamt.doc_7.3.0.1/rt/AMC_Editor/AMCE_profiles_select_transaction.html

http://pic.dhe.ibm.com/infocenter/tivihelp/v63r1/topic/com.ibm.itcamt.doc_7.3.0.1/rt/User_Guide/Robot/exportingrptscripts.html


Figure 51: Robotic data in the TEP console

39


6 Using the Application Performance Management User InterfaceIn this section, we use the Application Performance Management (APM) UI to manage performance and availability of Worklight applications. We configure and customize the APM UI to use the monitoring agents covered in the previous sections.

6.1 Configuring the data providerTo connect the APM UI to Tivoli Monitoring, the Common UI Rest Interface (CURI) must be enabled on the Tivoli Enterprise Portal Server. In the Tivoli Integrated Portal, create a connection as shown in the following figure:

Figure 52: Connection Panel in TIP

The connection in the summary table should display WORKING as shown below:

Figure 53: Connection Summary in TIP

Launch the APM UI, and click Settings to configure the data provider. The data provider is automatically displayed in the list of available providers.

Figure 54: Provider Configuration in APM UI


Next, let’s create an application with a dashboard.

6.2 Creating an application from a templateAdd a new application, create a name and description, select an application from the list, and select the application template. For each node, select one or more resources as shown in the figure below:

Figure 55: Application Configuration Panel in APM UI

Now, you can drill into each category and view the various dashboards. For instance, the figure below shows the resource dashboard for the FlightTicket application:

41


Figure 56: Resource Dashboard


7 ConclusionAfter you deploy this phased solution, you will realize significant value towards your overall application performance management strategy. You will be able to proactively detect performance and availability issues that impact the end-to-end monitoring. In phases one and two of this solution, we have seen how to deploy real-user and synthetic transaction monitoring. Finally, we introduced resource monitoring in phase three and observed the powerful features of the web server, application server, database and OS monitoring.

43

APPENDIX A

PRODUCT VERSIONS

Product/Component Release/Version Notes

SmartCloud Application Performance Management

7.6 For the Web Response Time agent, contact support to obtain APAR IV42379.

For the Robotic Response Time agent, contact support to obtain 7.3.0.1-TIV-CAMRT-LA0002.

Worklight 5.0.6

APPENDIX B

ADDITIONAL REFERENCES

Source URL

Application Performance Management User Interface on DeveloperWorks

https://www.ibm.com/developerworks/servicemanagement/apm/scapm/index.html

What is Port Mirroring http://www.miarec.com/faq/what-is-port-mirroring

Best Practices for Application Performance Management


Understanding the Pre-defined Authentication Realms and Security Tests in Worklight

http://goworklight.wordpress.com/2013/03/23/understanding-worklight-authentication-realms-and-security-tests/

vii





http://www.miarec.com/faq/what-is-port-mirroring



®

© Copyright IBM Corporation 2013IBM United States of AmericaProduced in the United States of America US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PAPER “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes may be made periodically to the information herein; these changes may be incorporated in subsequent versions of the paper. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this paper at any time without notice.

Any references in this document to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM Corporation4205 South Miami BoulevardResearch Triangle Park, NC 27709 U.S.A.

All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.

This information is for planning purposes only. The information herein is subject to change before the products described become available.

If you are viewing this information softcopy, the photographs and color illustrations may not appear.

Application Performance Management for IBM Worklight mobile apps

TrademarksIBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the web at "Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml.

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Other company, product, or service names may be trademarks or service marks of others.

9

Documents

IBM Application Performance Management for IBM Worklight … · 2013-06-13 · IBM® Cloud and Smarter Infrastructure Application Performance Management for IBM Worklight mobile applications