The availability and performance of BPEL process is dependent on two things:
BPEL ecosystem: If BPEL ecosystem is down, then the process will also be down. This dependency is more on an IT infrastructure.
Partner links: Generally BPEL process has multiple partner links where each partner link represents a call to a web service. Availability and performance of BPEL process also depends on the availability and performance of partner links. For example, lets assume that there is an "Employee Expense report BPEL process", and for all approved expenses it makes a web service call to the payment gateway for payments to the credit card company. In this imaginary scenario, if the web service for the payment gateway goes down, all of the expense reports will not be paid and that BPEL process will be considered down.
In case you didn't realize, your job as a BPEL Administrator just got more complex.
So far you were asked to monitor all the components of the BPEL eco system—now you have to monitor all partner links as well and many of them may be running outside your data centre.
The good news is that Enterprise Manager provides a model to manage this complexity. Before we go into the details of this model, lets revisit the concept of test and beacon.
In earlier chapters (4 and 5), we saw that we can record user actions and repeat those actions periodically to proactively monitor end user experience. These user actions are saved as tests and are executed from beacons. For monitoring of partner links we can use the SOAP test, where we can make a web service call to partner link every
•
The monitoring model that Enterprise Manager provides for BPEL process monitoring includes three services:
BPEL Infrastructure service: We learnt about this in the previous section, how this service represents all the components in BPEL ecosystem.
Availability service: This service represents all the availability tests for a BPEL process; it could include SOAP tests, Web transactions, and so on.
Aggregate service: This service is just an aggregate of the previous two services. Using this service you can monitor all the required metrics in one place. You can see the performance of your IT infrastructure as well as the performance of partner links in one place.
Again it may sound very complex to create or maintain this model, let's follow the listed steps to see how Enterprise Manager makes it easy:
1. Go to the Processes tab on a BPEL target homepage, click on one of the services and you will see a page that shows details of BPEL process. On this page you will see the option to Create Service, click on that to create an Aggregate service. The following screenshot shows the page that you will see after you have clicked on Create Service. You can see that the Infrastructure service is a part of this aggregated service.
•
•
•
2. From the Partner links section, select a partner link by clicking on the radio button next to it ,and click on Add SOAP Test, you will see the page as shown next. Please note that this page is dynamic, Enterprise Manager parses the WSDL and based on the WSDL definition, the data input fields may vary.
You may need to talk to your application administrator or owner to fill in those details.
3. Click OK on this page. On the next page you will be asked to select some beacons. The following screenshot shows that page:
4. Click OK and you will come back to the BPEL process page. You will notice that a new service is added. The name of this service is <BPEL process name
>_Availability and under this service you can see a SOAP test added.
You have completed the model of your BPEL process, using this model you can monitor all the dependencies for your BPEL process, that include:
BPEL ecosystem
Availability of partner links
SOAP test invokes the actual web service. If the web service is read-only, then there are no issues. If the web service does some updates to the business systems, then by submitting a SOAP test, you are creating some artificial transactions. Make sure that your application has a way to filter out, or ignore these transactions; these transactions should not be treated as regular business transactions. Generally, each application has some special IDs or credit card numbers that are ignored and those user-IDs/credit card numbers are used for such synthetic transactions.
If there is no way to filter out artificial transactions—DO NOT use the SOAP test or any other tests that create artificial transactions.
You can explore the other features of the aggregate service by visiting the aggregate service homepage. You can see availability and service levels for the service and you can drill down to Infrastructure service or individual components.
•
•
In case the service is down, you can see the root cause of that. The next screenshot shows one such case, where you can see that one of the SOAP tests is getting errors and that indicates that one partner link is down, and that is the root cause of BPEL process availability issues. It is violating the Service Level Agreements also.
Configuration management
We saw in the earlier chapters that Enterprise Manager collects configuration snapshots that are useful in keeping track of the configuration changes. Enterprise Manager refreshes the configuration snapshot periodically, and any change in the configuration is also recorded in the repository. You can also use the configuration snapshots to compare the configuration of one target with another target of the same type.
Configuration data collected for BPEL PM includes:�
SOAP URL and SOAP callback URL
Dehydration store details—host, port, s-id for dehydration store
•
•
List of the BPEL domains and domain specific configuration parameters like minimum and maximum threads
BPEL PM configuration files like collaxa-config.xml, jgroups-protocol.
xml, and so on
List of the BPEL processes deployed, and the artefacts for BPEL processes such as bpel.xml, xsds, wsdls, and so on
To see the latest collected configuration for a BPEL PM target, follow the steps listed next:
1. Go to the Administration tab on the target homepage and click on Last Collected Configuration link. The next screenshot shows the page:
•
•
•
2. Under the Processes tab, you will see a list of all BPEL processes. For each process, you will see the list of artefacts, last modification time for theartefacts, last modification time for the, last modification time for themodification time for the for the artefact, and size of the artefact. The next screenshot shows one such page:
3. Each artefact is a link. On clicking this link, you can see the content of the artefact that is stored in the Enterprise Manager repository. The following screenshot shows the content of an artefact:
To compare the configuration of a BPEL PM with another BPEL PM, follow the listed steps:
1. Go to the last collected configuration and click on the Compare button on the right side, you will be shown a page where you can select another BPEL PM with which you want comparison. The comparison screen will look like the figure shown next. From the Summary tab, you can see that there are differences in processes and configuration files.
2. From the Processes tab, you can see the difference in processes between two BPEL PMs, the following screenshot shows one such listing:
3. You can drill down further to see exactly what artefact has changed. To do so, click on the icon under the Results column, the next page will show the list of artefacts and the artefacts that have changed.