IBM® Business Process Manager (IBM BPM) is a comprehensive business process management platform. It provides tools to enable authoring, testing, and deployment of business processes, as well as management capabilities. See IBM documentation.

IBM BPM 8.5.7 is used to define and execute Business Process Definitions (BPDs) which combine elements of human interaction Client-Side Human Services (CSHS) or 'user tasks' for example, manual loan approvals and so on with elements of system integration system tasks, for example, registering a loan approval in a CRM system and so on. These processes are critically important and it is, therefore, natural to use AppDynamics Business Transactions to monitor the system integration elements of the processes to ensure the performance and reliability of these technical integrations. You can also use the AppDynamics Business Journeys capability to monitor the end-to-end progress of the processes, including the elements of human interaction.

AppDynamics Instrumentation Use Cases

To facilitate these monitoring use cases, the AppDynamics agent provides out-of-the-box configuration necessary to:

  • Appropriately start and name Business Transactions originated within IBM BPM to allow management of system tasks with App iQ APM 
  • Correlate the processing within IBM BPM to facilitate end-to-end tracing of these Business Transactions
  • Collect sufficient process metadata to allow these Business Transactions to be used within Business Journeys to provide visibility into the progress of processes including the human interactions

Agent Installation and Setup

IBM BPM runs in WebSphere, see IBM WebSphere and InfoSphere Startup Settings for more details.

Business Process Definitions: System and User Tasks

A BPD process consists of the flow of a business process which may involve user interactions. It consists of User Tasks, System Tasks, and other logic. 

The screenshot displays a sample process within the BPD designer:

User tasks, in turn, break down into one or more user interactions, such as submit a form and approve a decision. They can be implemented as a CSHS, one of which is shown below:

Business Process DefinitionCSHS

A CSHS always starts with a start event and consists of one or more activities each of which uses a system service as the underlying implementation, and one or more Coaches, which define the user interactions.

Business Transaction Support

Business Transaction Support for Client Side Human Services

CSHS Transaction naming

All Business Transactions detected within a CSHS are detected as servlet type transactions, and their naming can be configured using custom servlet naming rules. The default servlet naming rule uses only the first two segments of the URL for naming, hence, without custom naming configuration the Business Transactions will be detected as –

/<Project Name>/<BPD Name>

CSHS Transaction naming control

To disable the IBM BPM specific naming for CSHS Business Transactions use the disable-ibmbpm-usertask-bt-naming node property.

Since the Business Transaction is designed to monitor technical activity only, one CSHS may spawn multiple Business Transactions:

CSHS Business Transactions

Any element inside a CSHS is associated with the following identifiers:

  • Project Name
  • BPD Process Name
  • User Task Name 
  • CSHS Process Name
  • Activity Name or Coach Name

Additionally, for Activity (Service), the activity has a service as its implementation which has its own identifier (Service Name).          

These are annotated on screenshots of the IBM design tools:

BPD Screen  

BDP Screen

CSHS Screen  

CSHS Screen

Business Transaction Detection and Naming at the Start and End Points within a CSHS

Within a CSHS, there can be one or more activity-services involved in the flow. Each of this hits a specific REST URL. Hence, an HTTP entry point is defined for each of these services.

  • For example, the default URL for the Start BT – 
    /teamworks/process.lsw 
  • For example, the default URL for the End BT –
    /teamworks/cfecontroller

.CSHS Entry Points

Business Transactions originating from the start of a user task are detected as servlet Business Transactions and are named according to the following scheme:
/<Project Name>/<BPD Name>/<Task Name>/<CSHS Name>/Start:Event

For example (corresponding to the images shown above, BPD image and CSHS image), the Business Transactions would be named –
/My Hiring Sample/Standard HR Open New Position/Step: Submit job requisition/Client-Side Http Service/Start:Event
/My Hiring Sample/Standard HR Open New Position/Step: Submit job requisition/Client-Side Http Service/End:Event

Business Transaction Detection and Naming at an Activity (Service) Node Within a CSHS

Each user task in the BPD process has a CSHS as its implementation. Within a CSHS, there can be one or more activity-services involved in the flow. Each of them hits a specific REST URL. Hence, HTTP entry point is defined for each of these services.

For example, the default URL is –

/rest/bpm/wle/v1/coachflow/service/1.a22ce595-1573-4fdd-90f6-734884753610

CSHS Entry Points
Business Transactions originating within a CSHS activity service are detected as servlet Business Transactions and are named according to the following scheme:
/<Project Name>/<BPD Name>/<Task Name>/<CSHS Name>/<Activity Name>/<Implementation Service Name>:Service

For example (corresponding to the images BPD image and CSHS image), the Business Transactions would be named:
/My Hiring Sample/Standard HR Open New Position/Step: Submit job requisition/Client-Side Http Service/Activity1/HttpClient IService:Service

Business Transaction Detection at the CSHS Coach

A User Task in a BPD process has a CSHS as its implementation. Within a CSHS, there can be one or more UI Coach(es) involved in the flow. Each UI Coach represents the UI page(s) which opens up for the user to perform some actions (like completing a form, approving something, and so on). Each of these hits a specific REST–URL. Hence, the servlet entry point is used for the naming of the UI Coach.

For example, the default URL for this Business Transactions is –

/teamworks/generatecoachng

CSHS Business Transactions

Business Transaction Naming Scheme at Coach of CSHS

The Business Transactions originating on entry to a UI coach are detected as Servlet Business Transactions –
/<Project Name>/<BPD Name>/<Task Name>/<CSHS Name>/<Coach Name>:Coach

For example (corresponding to the images BPD image and CSHS image), the business transaction would be named:
/My Hiring Sample/Standard HR Open New Position/Step:Submit job requisition/Client-Side Http Service/UI Coach:Coach

In-Process Correlation Between Elements within a CSHS

There can be more than one element involved within a User Task (CSHS) with no user interaction in between them. These form a part of the same business transaction. Service Endpoints give visibility of the individual steps within the resulting business transaction as illustrated below:

CSHS Service Endpoints

Business Transaction Support for System Tasks within a BPD Process

POJO business transactions are generated for System Tasks within a BPD process.

The POJO business transactions are named using four identifiers:

  1. Project Name (<project-name>)
  2. BPD Process Name (<bpd-name>)
  3. System Task Name (<task-name>)
  4. Implementation Process Name (<implementation-name>)

If any identifier's value is not available, it is replaced with <UNKNOWN> in the resulting transaction name.

For example, a business transaction detected for default configuration (<project-name> / <bpd-name> / <task-name> / <implementation-name>) is:

Business Transactions

The default naming scheme can be customized using the ibmbpm-systemtask-bt-naming node property.

The property value is comma-separated identifiers chosen from project, bpd, task, implementation, and is order sensitive.
For example if,

 value = "project, task" means POJO Business Transactions are named as: <project-name>/<task-name>

 value = "task, project" means POJO Business Transactions are named as: <task-name>/<project-name>
 value = "none" means POJO Business Transactions are not detected (disabled)
 value = "default" means all the identifiers are used for Business Transactions naming in a default order, that is, they are named as <project-name>/<bpd-name>/<task-name>/<implementation-name>

Set ibmbpm-systemtask-bt-naming property to "none" to disable detection of Business Transactions for system tasks.

Built-in Data Collectors

Controlling the Built in Data Collectors

To disable the out of the box data collectors use the disable-ibmbpm-data-collectors node property.

For a System Task or a User Task, the following data collectors are available:

  • PROCESS NAME
  • TASK ID 
  • TASK NAME
  • BPD INSTANCE ID
  • BPD NAME
  • PROJECT NAME

In addition to these, for a CSHS implementation of a User Task, if the IBM BPM specific naming Business Transactions naming scheme is enabled, an additional data collector, ACTUAL URL, will also be present, populated with the actual URL hit when the business transaction is initiated.

Additional data collectors defined for a User Task depending upon the element of the CSHS being called can be:

  • COACH NAME for Coach

  • EVENT TYPE for Start and End (value is either Start or End depending upon on the event)

  • ACTIVITY NAME for Activity (Service) 
  • SERVICE NAME for Activity (Service – denoting the implementation service of the activity)

Sample Data Collectors

You can view the snapshot data collectors as:  

  • Data Collectors for System Task
    Snapshot Data Collectors
  • Data Collectors for Start Event of CSHS in User Task
    Snapshot Data Collectors
  • Data Collectors for Activity (Service) Element of CSHS in User Task
    Snapshot Data Collectors
  • Data Collectors for Coach Element of CSHS in User Task
    Snapshot Data Collectors
  • Data Collectors for End Event of CSHS in User Task
    Snapshot Data Collectors

Configuration Notes

There are some other configuration settings that may be helpful when implementing AppDynamics for IBM BPM monitoring:

  • Increase the value of the node-property max-business-transactions if necessary, to accommodate the number of tasks involved in the BPD process (the default = 50).
  • Add a node property framework-support with a value of "none" to disable CometD and GWT POJO Business Transactions a large number of which otherwise get detected. These correspond to activity within the IBM tooling and are not valuable for BPM monitoring.
  • Exclude Servlet Business Transactions like /portal/login, /webasset/..,  which are not valuable for BPM monitoring. 

Node Properties That Control IBM BPM Instrumentation 

Node Properties available when using IBM-BPM support:

  • disable-ibmbpm-usertask-bt-naming: Sets whether Business Transactions naming scheme for IBM-BPM UserTask Business Transactions should be disabled (value = true) or enabled (value = false).
    When it is set to "true", the Business Transactions would be named as per the default URL and not the meaningful names.
  • disable-ibmbpm-usertask-bt-in-process-correlation: Sets whether Business Transactions in-process correlation for IBM-BPM UserTask Business Transactions should be disabled (value = true) or enabled (value = false).
  • ibmbpm-systemtask-bt-naming: Decides Business Transactions naming scheme for IBM-BPM System Task POJO Business Transactions.
  • disable-ibmbpm-data-collectors: Sets whether data-collectors for IBM-BPM task Business Transactions should be disabled (value = true) or enabled (value = false).