Tutorials
Delve into End-to-End Monitoring user journeys through step-by-step tutorials.
Delve into End-to-End Monitoring user journeys through step-by-step tutorials.
As a part of the user journey, we have two actors who play the following roles:
Jim – An IBM webMethods customer who owns an enterprise called XYSsales and sells many products on his business platform. To run his business better, he uses products like IBM webMethods API Gateway, IBM webMethods Integration, and IBM webMethods B2B. XYSsales has a large customer base where every day new customers create their accounts on his business platform.
Hayley – A prospective customer of Jim. She wants to create an account in XYSsales.
Jim reviews many business transactions in a day. These transactions move across the various IBM webMethods applications. Reviewing the transactions helps Jim identify areas of improvement and any errors. In this scenario, XYSsales uses both IBM webMethods API Gateway and IBM webMethods Integration. Jim can view the details of the transactions within the individual systems. For example, on an API execution, he can view its details using the logs in IBM webMethods API Gateway. In the same manner, when an integration is run, he can view its details using the logs in IBM webMethods Integration. However, if an API calls an integration in IBM webMethods Integration, the log information does not tell Jim which integration in IBM webMethods Integration corresponds to which API execution in IBM webMethods API Gateway.
To summarize, Jim is unable to correlate the information when a business transaction traverses through multiple systems. He is unable to view the end to end details of a business transaction. We are helping Jim solve this problem by introducing End-to-End Monitoring.
Hayley sends a request to create a user account using a client application. This triggers a business transaction. Jim wants to view the complete flow of this business transaction. He wants to know the details from the time Hayley sent the request to the time she received the response.
As part of the prerequisites, Jim performs the following actions:
Creates a connection from XYSsales to IBM webMethods Integration by creating an account in IBM webMethods Integration.
Creates an integration called CreateAccountinXYSsales in IBM webMethods Integration. He exposes this integration as a REST endpoint such that any client can access it.
Creates an API called APItoCreateAccountinXYSsales in IBM webMethods API Gateway. This allows him to make a connection with the REST endpoint created in the earlier step.
When Hayley sends a request to create a user account in XYSsales using the client application, following events take place:
The client application calls the REST API APItoCreateAccountinXYSsales. The system applies all the policies defined for this API at this stage of the transaction.
After successful authentication of Hayley’s account credentials with IBM webMethods API Gateway, the API invokes the integration CreateAccountinXYSsales, which is the REST endpoint.
The integration is run and it creates the user account for Hayley in XYSsales. On successful creation of the account, the system sends a confirmation message as a response to Hayley through the client application.
Jim can view the details of the API execution through the Analytics tab of the IBM webMethods API Gateway cloud instance:
Jim can also view the details of the integration using the Monitor tab of the IBM webMethods Integration instance:
Jim logs into IBM webMethods Integration.
He selects End-to-End Monitoring from the App Switcher:
Jim opens the Dashboard of IBM webMethods End-to-End Monitoring to view all the transaction groups. By default, the duration selected for view is last half an hour from the current system time. Jim can see the following details:
He selects the group XYSsales which lists all the transactions associated with his enterprise.
He selects the transaction which he wants to view.
On the Business Transaction Details page, he can view all the information for that business transaction:
On the Business Transaction Details page, he can get more details for each component of the transaction by selecting the component on the Business flow map. When he selects the component, the details are shown in a new pane. For example, Jim selects the Integration Cloud component and he can view the details as shown in the following image.
This completes the user journey for Jim.
As part of this user journey, we have two actors who play the following roles:
John – An IBM webMethods customer who owns an enterprise called XYSsales and sells many products on his business platform. To run his business better, he uses products like IBM webMethods API Gateway, IBM webMethods Integration, and IBM webMethods B2B. XYSales has numerous partner enterprises. XYSsales uses IBM products for their business solutions as well as in-house products.
Emma – An employee of an enterprise XYZTrade, an enterprise partner of XYSales.
XYSales has built solutions for its finance department in XYSsalesFinanceDev development environment.
The enterprise has the same solutions deployed in a production environment XYSsalesFinanceProd.
XYSales logistics department has an ongoing solution being built in XYSsalesLogisticDev development environment.
John reviews numerous business transactions in a day. These transactions move across various environments, stages, and IBM applications. When a transactions fails, John has difficulty in finding out which specific product caused the failure. John also needs to find out the root cause of slow transactions.
A customer of XYSales does a business transaction with partner enterprise XYZTrade.
On successful completion of this transaction, they invoke IBM webMethods Integration Flow services to perform some logical operations.
XYSales exposes this transaction through an API Gateway API to control the transaction invocation. Policies like authorization and throttling are used to achieve this control. The API Name is InvokeXYSsalesInfo.
Emma executes the above described transaction and John needs to view the flow of this transaction to analyse issues and delays.
Tenant | WMIO Flow | B2B Channel | API Gateway |
---|---|---|---|
XYSsalesFinanceDev | ComputeXYLogisticAccountCount | XYSsalesChannel, Sender:XYSsales | InvokeXYSsalesInfo |
Root Cause
John logs into his IBM webMethods iPaaS tenant XYSsalesFinanceDev. It lists all the products that he currently uses for his business needs.
John selects IBM webMethods Integration, and then the Monitor tab to view all transactions specific to IBM webMethods Integration.
He selects End-to-End Monitoring using the app switcher.
John selects Administrator on his user profile link and ensures that the environment group listing is setup right, to view his transaction.
He selects a time range to cover the time window of Emma’s transaction.
John now makes Environment group and Stages in View selections on the masthead filters to simplify locating his transaction.
John is able to locate the transaction he is looking for within the All Transactions group.
Selecting the transaction allows him to view the full flow of the business flow map, and also shows him the finer details of time delay and the reason for any failure, if any.
For further details, John clicks on the More details link of that product and traverses to that product’s monitoring page.
This use case is an exact replica of use case 1, with the only exception that this is deployed in the production environment. Hence, John will be executing the same set of steps listed above with the following exceptions:
Tenant | WMIO Flow | B2B Channel | API Gateway |
---|---|---|---|
XYSsalesFinanceProd | ComputeXYLogisticAccountCount | XYSsalesChannel, Sender:XYSsales | InvokeXYSsalesInfo |
Root Cause
This time, John logs into his IBM webMethods iPaaS tenant XYSsalesFinanceProd.
He verifies the environment group listing and selects the time range just as in use case 1.
His masthead filter selections will now be Finance and Production.
He now easily locates his production transaction and looks into more details.
This use case is deployed for John’s logistics department. In order to calculate some expenses, they receive data from the finance department. In this new environment, they call a REST API from XYSsalesFinanceDev and then processes it in a workflow to calculate some expenses for the logistics department.
Tenant | Finance WMIO REST API | Called WMIO workflow | Logistics WMIO workflow |
---|---|---|---|
XYSsalesLogisticDev | GetConsumedCouponDetails | ConsumedCouponDetails | ComputeConsumtionOnGivenDates |
Root Cause
John logs into his IBM webMethods iPaaS tenant XYSsalesLogisticDev.
He verifies the environment group listing and selects the time range just as in use cases 1 and 2.
His masthead filter selections will now be Logistics and Development.
He locates the logistics transaction and looks into more details.
As part of this user journey, we have two actors who play the following roles:
John – An IBM webMethods customer who owns an enterprise called XYSsales and sells many products on his business platform. To run his business better, he uses products like IBM webMethods API Gateway, IBM webMethods Integration, IBM webMethods B2B, and Integration Server. XYSales has numerous partner enterprises. XYSsales uses IBM products for their business solutions as well as in-house products.
Emma – An employee of an enterprise XYZTrade, an enterprise partner of XYSales.
XYSales has built its solutions using IBM cloud products and on-premises webMethods Integration Server.
XYSales product delivery management solution is hosted in on-premises Integration Server. XYSales uses IBM webMethods Integration On-premise Connectors feature to integrate its product delivery management part of the business solution with other parts of the business solutions hosted in IBM cloud products.
John reviews numerous business transactions in a day. These transactions move across many IBM cloud solutions and webMethods Integration Server. When a transaction fails at Integration Server, Emma has difficulty in analysing the failure as there is no solution that tracks transactions between cloud and on-premises products.
A customer of XYSales does a business transaction with partner enterprise XYZTrade.
On successful completion of this transaction, they invoke IBM webMethods Integration workflow to perform logical operations and then invoke product delivery management hosted in Integration Server.
XYSales exposes this transaction through an API Gateway API to control the transaction invocation. Policies like authorization and throttling are used to achieve this control. The API Name is InvokeXYSsalesInfo.
Emma executes the above described transaction and John needs to view the flow of this transaction to analyse issues and delays.
Tenant | WMIO Flow | B2B Channel | API Gateway | Integration Server |
---|---|---|---|---|
XYSsalesSCM | XYSSCMComputetaionsAndProductDeliveryManagement | XYSsalesChannel, Sender:XYSsales | InvokeXYSsalesInfo | XYSDeliveryManagementServices |
Root Cause
John logs into his IBM webMethods iPaaS tenant XYSsalesSCM. It lists all the products that he currently uses for his business needs.
John now selects IBM webMethods Integration, and selects the Monitor tab to view all transactions specific to IBM webMethods Integration.
He selects End-to-End Monitoring using the app switcher.
He selects a time range to cover the time window of Emma’s transaction.
John is now able to locate the transaction he is looking for within the All Transactions group.
Selecting the transaction allows him to view the full flow of the business flow map, and also shows him the finer details of time delay and the reason for the failure, if any.
If failure of the transaction is in the on-premises Integration Server node, John can expand the node and analyse the individual services for failures and delays.
For an in-depth analysis, John checks the End-to-End Monitoring Hybrid Integration log files in the on-premises webMethods Integration Server file system:
<Install-Dir>/IntegrationServer/instances/default/logs