Services

From IBM BPM
Jump to navigation Jump to search

Events in relation to a BPD characterize the general process flow and can be visualized from the diagram for a clean and readable perspective. Conversely, a BPD indicates huge amounts of information but does not provide the functionalities concerning the actual implementation of the process. Consider a very simple process of how you prepare your cup of tea in the morning.

Each step is executed using the idea of a service in IBM BPM. A service can be thought of as a reusable implementation of some specific function of which the caller is ignorant of its completion. Within BPDs, every activity in a diagram is mapped to a service and, at runtime, the corresponding service is triggered as soon as that step in the process is reached.

Services are typically invoked from the activity step of a BPD, with the service to be invoked within the confines of a given activity defined in the Implementation tab.


Events in relation to a BPD characterize the general process flow and can be visualized from the diagram for a clean and readable perspective. Conversely, a BPD indicates huge amounts of information but does not provide the functionalities concerning the actual implementation of the process. Consider a very simple process of how you prepare your cup of tea in the morning.

Each step is executed using the idea of a service in IBM BPM. A service can be thought of as a reusable implementation of some specific function of which the caller is ignorant of its completion. Within BPDs, every activity in a diagram is mapped to a service and, at runtime, the corresponding service is triggered as soon as that step in the process is reached.

Services are typically invoked from the activity step of a BPD, with the service to be invoked within the confines of a given activity defined in the Implementation tab.

Result caching in a service

A service executed with a set of parameters returns a result set. If the same service with the same input parameters is run several times, chances are it is going to return the same output, but behind the scenes, the logic of the service will be processed every time. We can turn on a feature that will let the service cache its results for better performance. It means that once a service has been executed with some given input, the results are cached. If the same service is requested again and the same inputs are given exactly, the previously stored results are returned and the logic of the service does not have to be executed again.


This can be enabled or disabled on a per-service basis. In the Overview tab of any service definition, there will be an entry called "Service Result Cache."

By default, service caching is turned off. The results of the service are cached when this option is checked, and you can further specify for how long a cached result is valid before it is considered "stale". You can set an interval of your choice so that once the specified time has passed, a previously returned entry is considered outdated and the actual service is run once again.

By default, the caching mechanism in IBM BPM supports 4096 entries in the cache. One could do this by modifying the property <service-result-cache-size> in the configuration files.

Human Service

The Human Service is arguably the most significant service type in IBM BPM. This is a component whose execution creates a task for a human end-user to accomplish, with the BPD process having paused until this task is completed. Human Services also allow for including Coach components that define both what screen data will be presented to users, and how the data will be collected from them.

With the new release of IBM BPM 8.5.5, the implementation of Human Services has changed quite a bit. The new version introduced a new kind of Human Service called "Client-Side Human Services." The previous implementation was then renamed to "Heritage Human Services" to preserve the backward compatibility of solutions developed before 8.5.5.

Exposing of Human Service

In the Overview panel of the Human Service definition, under the Exposing section, you will define how the service will be exposed for initiation through other means than it being explicitly called by a BPD.

You can also set several options for how the Human Service may be accessed, like exposing as an URL, making it available as a Dashboard, or allowing to be started from Launch from Process Portal. The options make the service very flexible in terms of how it might be triggered—for example, integration with some external systems or simply to let users start a service from outside the standard flow of BPDs.

Timeout in Human Service

hen a process comes to a step that involves a Human Service, that means a staff member has to do something. But if he or she becomes too time-consuming, or simply is not available, then it will pause—or hang—the process. Rather than letting the process hang, you may want it to timeout the Human Service and take another action, such as reassigning the task to a manager or other person.

This can be implemented by means of a Timer Event pinned to the Human Service activity.

In the case of a raised Timer Event that closes the activity that a claimed and started Human Task without completion belongs to, a notification to the user about their input being discarded is not sent.

Human Service (Client Side)

Contrary to this, the whole concept of Human Services changed dramatically with the introduction of IBM BPM 8.5.5. The former unique Human Service actually split into two different types: the classic Human Service was renamed to "Heritage Human Service," and the other one was introduced as a new type, "Client-Side Human Service". To understand the difference, we need to look at how IBM BPM handled Human Services prior to 8.5.5. We will set the basis of new concepts. In explanation, we use already the new terminology of 8.5.5.

Execution of a Heritage Human Service includes a mix of logic running within IBM BPM and logic running in the browser. Server scripts or data manipulation steps are always executed in the BPM run-time environment. When a Coach is reached, the HTML for that Coach, along with the associated JavaScripts, is generated and sent to the browser. At this point the Heritage Human Service pauses, waiting for the user to submit data from the Coach web page. When the data is submitted, the Heritage Human Service resumes control and continues its process. If Heritage Human Service meets a second Coach, the cycle begins again: Yet another new page of data is dispatched to the browser, and the Heritage Human Service's run-time code suspends once more. This type of interaction back and forth between the browser and the BPM run-time environment is characteristic of Heritage Human Services.

Scripting in Client Side Human Services

Scripting in IBM BPM typically allows you to use a variety of IBM-provided classes and functions. For instance, to create a new Business Object instance, you would write:

var myVar = new tw.object.MyBusinessObject();

Or, if you wanted to create a list, you might use:

var myList = new tw.object.listOf.MyBusinessObject();

However, all that has changed under Client-Side Human Services and other client-side scripting environments. In this context, you directly program as if you are writing native JavaScript running in a browser – which in fact you are. That means you no longer create these special IBM BPM objects, instead deal with standard JavaScript types.

Example:

var myVar = {};

and

var myList = [];

The underlying lists have some additional properties that tell which, in case, of the items in the list are actually selected in the server side scripting environment when one wants to deal with the lists. It is part of the client-side human server, although the manipulation in the class is slightly different, the single-class property identifies which items in the list are selected. This is a property listAllSelectedIndices which is an index value array into the list (array). The entries here are the ones considered as selected indices.

End Event Navigation

Within a Human Service, there will inevitably be some point at which the service ends, usually by reaching an end event. When this happens, the interaction between the user and the process is ended at this point. For instance, the user may be shown a screen with fields to fill in; the user fills in the data and the Human Service exits. But what should then be shown to the user?

In the Implementation tab, there is an option called "Navigation type" that enables the selection among some predefined values. These options determine what would be shown to the user next.

  1. Default (behaviour provided by Default UI)
  2. URL (Redirect to user defined URL)

Ajax Service

Integration Service

It enables a process to invoke an external entity, for instance, a Web Service or even a piece of Java Code. One of the components of integration service is utilized to get in touch with the logic existing outside the BPMN environment and the true SOA external service.

Decision Service

External Service

External Service from JavaScript

Server Scriptlet

The purpose of this element is to assign text to a variable but have a very simple text input field for ease of entry.

Postpone Task

The postpone element allows a task to postpone the completion of its processing until later. In other words, its completion is deferred. The state of the service is set aside for later resumption. At the postpone point, the task moves back into the inbox where it can be picked again. If we want to hide the task for some time, more needs to be done. One possible solution would be a check at the end of the Coach for any suspension of the task and, in case of yes, delaying the re-creation of it for some time.