Application Performance Management for IBM Worklight mobile applications

Transcription

1 IBM Cloud and Smarter Infrastructure Application Performance Management for IBM Worklight mobile applications Document version 1.0 John Griffith Larry McWilliams Mark Weatherill Ren Fu Ma Qi Gang Zhu

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

3 Application Performance Management for IBM Worklight mobile apps apdddpl CONTENTS Contents...iii List of Figures...vi List of Tables...ix Revision History...x 1Introduction...1 2Use Case Scenarios Use Case 1: Real-user monitoring Use Case 2: Synthetic transaction monitoring Use Case 3: Resource monitoring Typical Worklight Environment Phase 1: Real User Monitoring Architectural Overview Real User Monitoring Component Deployment Phase 2: Synthetic Transaction Monitoring Architectural Overview Synthetic Transaction Monitoring Component Deployment Phase 3: Resource Monitoring Architectural Overview Resource Monitoring Component Deployment...13 iii

4 Application Performance Management for IBM Worklight mobile apps applicationsdfsdf 4Configuring Real User Monitoring Defining a Worklight Application in the Application Management Configuration Editor Configuring user and session tracking Defining Worklight Transactions Create a monitoring profile Defining client groups Verifying WRT is capturing data using the console Configuring Synthetic Transaction Monitoring Installing the Worklight Application onto a test device Configuring the test device to use the Rational Performance Tester proxy Recording a script in Rational Performance Tester Modifying the script for playback Handling Worklight authentication realms Organizing requests into high-level transactions steps Adding verification points Uploading and scheduling robotic playback in ITCAM for Transactions Using the Application Performance Management User Interface Configuring the data provider Creating an application from a template Conclusion...43 iv

5 Application Performance Management for IBM Worklight mobile apps apdddpl Appendix A...vi Appendix B...vii v

6 Application 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

7 Application Performance Management for IBM Worklight mobile apps 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

8 Application Performance Management for IBM Worklight mobile apps 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

9 Application Performance Management for IBM Worklight mobile apps REVISION HISTORY Date Version Revised By Comments MW Initial version ix

10 1 Introduction The 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

11 2 Use Case Scenarios In 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 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

12 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

13 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.

14 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

15 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.

16 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

17 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 Environment The 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. Legacy Backend 1 Load Balancer IBM HTTP Server W orklight Cluster Legacy Backend 2 Mobile Clients W orklight database Figure 5: Typical Worklight topology. 3.2 Phase 1: Real User Monitoring Real 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.

18 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. Application Management Console agent SmartCloud APM infrastructure Worklight Environment W eb Response Time agent Legacy Backend 1 Load Balancer IBM HTTP Server W orklight Cluster Legacy Backend 2 Mobile Clients W orklight database 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 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

19 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 product version and maintenance levels, refer to the ITCAM for Transactions entry in Appendix A. For more details on installing and configuring the WRT agent, refer to the following sections from the SmartCloud APM information center: Installing Response Time monitoring agents and related software 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 Architectural Overview 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.

20 Robotic Response Time agent Application Management Console agent SmartCloud APM infrastructure Worklight Environment W eb Response Time agent Legacy Backend 1 Load Balancer IBM HTTP Server W orklight Cluster Legacy Backend 2 Mobile Clients W orklight database 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. Application Management Console agent Rational Performance Tester Load Balancer Real or virtual devices Figure 8: Recording synthetic transactions with Rational Performance Tester. 11

21 3.3.2 Synthetic Transaction 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: 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 product version and maintenance levels, refer to the ITCAM for Transactions entry in Appendix A. For more details on installing and configuring the RRT agent, refer to the following sections from the SmartCloud APM information center: Installing Response Time monitoring agents and related software 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 product version and maintenance levels, refer to the ITCAM for Transactions entry in Appendix A. 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 Monitoring Resource 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.

22 3.4.1 Architectural Overview 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. Robotic Response Time agent Application Management Console agent SmartCloud APM infrastructure Worklight Environment W eb Response Time agent W ebsphere agent OS agent Load Balancer Mobile Clients IBM HTTP Server Legacy Backend 1 W orklight Cluster Legacy Backend 2 HTTP agent OS agent W orklight database DB2 agent OS agent Figure 9: Resource monitoring using application and OS agents Resource Monitoring Component Deployment In this section, we summarize the basic installation for this capability. If applicable, special notes or nuances are explained. 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

23 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 product version and maintenance levels, refer to the ITCAM for Applications entry in Appendix A. 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 product version and maintenance levels, refer to the ITCAM for Applications entry in Appendix A. For more details on installing the HTTP agent, refer to the following sections from the SmartCloud APM information center: Agent for HTTP Servers

24 4 Configuring Real User Monitoring In 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: 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 Defining a Worklight Application in the Application Management Configuration Editor From 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

25 4.2 Configuring user and session tracking Configure 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.

26 4.3 Defining Worklight Transactions Worklight 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/* Name Value Application name Flight Ticket Transaction name query/$http.post:adapter$/$http.post:procedure$ Server name $IPDestinationAddress$:$DestinationPort$ Reporting Table 4: Transaction definition for Application API requests Transaction Name Application API requests Transaction Type HTTP/S Name Value URLPath *apps/services/api/flightticket/* Name Value Application name Flight Ticket Transaction name $URLFile$ Server name $IPDestinationAddress$:$DestinationPort$ Filter Reporting Table 5: Transaction definition for Logout 17

27 Transaction Name Logout Transaction Type HTTP/S Logoff True Filter Name Value URLFile Logout URLPath *apps/services/api/flightticket/* Name Value Application name Flight Ticket Transaction name query/$http.post:adapter$/$http.post:procedure$ Server name $IPDestinationAddress$:$DestinationPort$ Reporting 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 :

28 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 profile Create 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

29 4.5 Defining client groups As 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 console Once 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.

30 Figure 19: Application Interactions workspace 21

31 5 Configuring Synthetic Transaction Monitoring In 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: 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 Installing the Worklight Application onto a test device In 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:

32 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

33 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., After installation, you will see the icon in the Apps Panel:

34 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

35 Figure 27: Wireless & networks Figure 28: Wireless & networks Figure 29: Mobile network settings

36 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 , the use the following settings: Figure 31: Edit access point 5.3 Recording a script in Rational Performance Tester In 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

37 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.

38 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 Figure 34: Application recording 29

39 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.

40 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

41 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 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.

42 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

43 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. header Token this value needs to passed in the Authorization HTTP 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:

44 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

45 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 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

46 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

47 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:

48 Figure 51: Robotic data in the TEP console 39

49 6 Using the Application Performance Management User Interface In 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 provider To 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

50 Next, let s create an application with a dashboard. 6.2 Creating an application from a template Add 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

51 Figure 56: Resource Dashboard

52 7 Conclusion After 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

53 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 IV For the Robotic Response Time agent, contact support to obtain TIV-CAMRT-LA0002. Worklight 5.0.6

54 APPENDIX B ADDITIONAL REFERENCES Source URL Application Performance Management User Interface on DeveloperWorks /index.html What is Port Mirroring Best Practices for Application Performance Management /index.html Understanding the Predefined Authentication Realms and Security Tests in Worklight vii

55 Copyright IBM Corporation 2013 IBM United States of America Produced 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 Licensing IBM Corporation North Castle Drive Armonk, NY 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 Licensing IBM Corporation 4205 South Miami Boulevard Research Triangle Park, NC 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.

56 Application Performance Management for IBM Worklight mobile apps Trademarks IBM, 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 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