IBM BPM - Enabling resumable services (zResumable) - what you should know



As of version 8.5.x of IBM introduced a new service invocation feature called “resumable”.

The intent of this feature was to solve a long standing memory (heap) consumption issue as well as support the service based dashboard capability now available within IBM BPM Portal.

While the official documentation for this new feature can be found within IBM’s Knowledge Center document here, it does not explain the specific scenarios or potential “gotcha’s" that surround this new feature.
The intent of this document is to highlight the behavior of this new feature, how it differs from the legacy behavior and when the use of the “resumable” feature makes sense.
NOTE: If you're running on IBM BPM 857 (CF 2017.03) or later take a look at the newly added section here.

Here is a list of important things to know about this property that are not covered in the official IBM documentation

  1. The “Never Ending Service"
    The never ending service issue is described here and can result in significant heap use which may impact stability of the BPM environment as a whole. The problem results from a stand alone service, typically a dashboard, that renders a coach. Because the service doesn’t actually hit an end state, the managed bean remains in memory until such time as it times out (default timeout is 2 hours). If a dashboard is used often and includes large arrays of data, it is possible that the accumulation of managed service beans will severely impact available heap to the remainder of the application.
    Resumable services resolve this problem by allowing a given service been to be re-entered for a given session. This means a new service is not started on each service call and heap usage is significantly reduced.

    See an update below on how this works in Client-side Human Services (CSHS).

  2. IBM BPM Process Portal vs REST API

    Knowledge Center doc says you need to configure the "" property in the WAS Admin Console and include the Process Apps in the value of the property if you want your dashboards form that Process App to be resumable.
    Why does running a dashboard using the URL from the REST API appear to be "resumable" even without setting the property?
    The answer is - the "" property is only used by the Process Portal (you may notice that if you launch a dashboard from the Process Portal without this parameter set it does not use the zResumable=true.)
    So, the property - "" property is to "make" dashboards resumable when executed from IBM BPM Process Portal only.
    Once you add this property and specify process apps that have your dashboards, dashboards will be launched from Process Portal with zResumable=true. Basically you would have to set the "" WAS property and update that property to include EVERY Process App that you want to have the "resumable" functionality.
    IBM BPM REST API's does NOT take this "" WAS property into consideration. This means that ALL dashboards that you execute using the REST API exposed services URL's would be resumable by default. We are working with IBM on this issue and it's not yet confirmed whether it's working as designed and not as desired or whether it's a defect in the Product.

  3. Heap consumption

    Depending on your BPM solution you might see adverse effects when you use this property to try to alleviate never ending service/heap consumption issue(s), e.g. you might start seeing more heap consumption when you set this property for one or multiple of your process applications. So, if you do decide to use this property for your process app(s) then make sure you perform load/performance testing before/after the change and compare results, especially heap consumption statistics.

  4. Multi page dashboard

    Another side effect of resumable services that may not be immediately evident is that of entry point on resumption.
    Many custom dashboards include multiple coaches which act as either drill downs or other views of a given data set. However, when a resumable service is called, the last saved state of the service is what is presented (rather than the normal service start) which may mean the dashboard immediately renders within a drill down or alternate view. This behavior has caused some confusion and meant rework for existing dashboards that assumed the legacy behavior.

  5. Feature request

    Finally, BP3 Labs team believes that this property would be better to be configured on per dashboard/admin service basis and not per process application basis. We believe it is something that a developer should decide on and code the logic of the dashboard/service accordingly.
    We've submitted an RFE to “Make services resumable on per-service basis configurable via PD”. Please vote for it, if interested.

UPDATE AS OF IBM BPM 8.5.7 CF2017.03

Heritage Human Service (HHS):

  • zResumable requires property to include the acronym of the process app with the dashboard to be resumable, otherwise it won't work
  • In Process Center, zResumable flag works only for named snapshot in Process Center (PC). Anything exposed in TIP is ignored in PC, regardless of property. That is, an instance of a BPM Service Engine bean gets created (CreateCount increases, but RemoveCount remains the same in PMI monitoring) every time the dashboard service get's executed. Therefore, the service always gets started from the beginning.
  • zResumable also works for HHS exposed as URL
  • There are additional properties (zForceNew=true and zClientHandle={key}) which can be used with zResumable=true to fine tune the behavior

Client-side Human Service (CSHS):

  • zResumable property does NOT work with CSHS (not even documented for CSHS), but for some reason is still being added to exposed dashboard URL
  • BPM Service Engine bean gets created ONLY when there is a server side service call
  • Upon server side service call form CSHS an instance of BPM Service Engine bean gets created and immediately destroyed, i.e. CreateCount and RemoveCount increase at the same time by the same value in PMI Monitoring.
  • Due to the above, it looks like "never ending human service" is no longer a concern for CSHS from the memory utilization perspective, but might be slower upon server side service calls due to re-creation of the bean (haven't measure the actual overhead). Therefore, it makes sense to avoid "sequential" server side service calls by consolidating such services into a single service to be called form CSHS.

Additional links/official documentation for IBM BPM 857 (applicable for 86 as well):

zResumable in HHS

Defining usage settings for root client-side human services:

Have more questions? Submit a request


  • Avatar
    Sergei Malynovskyi

    Here is the official answer from IBM PMR with regards to item #2 in this article -

    1) Dashboard resumability was added in BPM V8.0.1 in large part to
    improve performance, especially since dashboards by their nature are
    typically "static" in that there is usually one stateless coach that is
    displayed, as opposed to representing a process instance / task flow
    with multiple states and true start and end nodes.  Keeping one instance
    of a dashboard in memory as opposed to multiple instances per launch
    within a user session (Process Portal or custom portal) is much more

    2) With 1) in mind the exposed item REST API was modified in V8.0.1 to
    include zResumable=true in the runURL property for all dashboard items,
    making this the de facto default behavior, consistent with Process
    Portal (all dashboards launched via Process Portal are resumable).

    3) Configurability of dashboard resumability for dashboards launched via
    Process Portal was added in BPM V8.5 with the Mashups_ConfigService property.  It was
    only intended for Process Portal usage, however, so the exposed REST API
    maintained its previously established behavior in V8.5 forward.

    In conclusion, the exposed REST API and the property is working as designed (but obviously not as desired).  For a
    custom portal, a scheme similar to that for the property can be
    implemented, or, in the case of this customer where resumability isn't
    needed/wanted at all, zResumable=true can be stripped programmatically
    from the runURL for all dashboard items.  Changing the REST API to not
    include zResumable=true would impact all customers who use the API,
    potentially introducing unexpected performance degradation. 

Powered by Zendesk