BPM, Workflow, and Case

Let's Understand the Caching Feature of IBM BPM Services

IBM BPM provides a feature of caching service outputs for unique combinations of input values upto a certain number (configurable) of combinations.

To enable caching in a service we need to navigate to the “Overview” tab of the service and click on the “Enable caching of service results” checkbox. As soon as the checkbox is checked, four boxes with different time units (Days, Hours, Minutes and Seconds) will appear and we can easily configure the required duration of keeping the cache.

As shown below – 

Now, let’s see the limitations and other important configurations related to service caching – 

Limitation: 

The service result cache works only for top-level services that are called directly. If a service is called within another service as a nested service, the cache setting does not apply. We’ll see how can we manage this limitation later in this tutorial.

Configurations:

• By default, the cache stores up to 4096 results, that means it can cache output results for upto 4096 input parameter combinations.
• This value is configurable in 100Custom.xml file by setting a different value for <service-result-cache-size>

Let's create a general system service - will cache the results of this service.

So, I have created a general system service “SampleCacheService” which will take service name as input and provide the service id back as output using the system JS API.

I have enabled the caching as shown above.

The I/O mapping is like – 

In the service I have implemented a script block to retrieve the service id like – 

And simply the code is  – 

I have added this log info to make sure whether the service is called or not.

The Trick - Let's try to call the cached service from a human service to visualize the result

I have created a simple human service with a coach with one input text, output text and one button. The idea is to get the service id after entering the service name and clicking on the button.

The trick: If you see the service diagram, instead of calling the cached service as a nested service, I have added a script block which will be calling the cached service using JavaScript API.

I have implemented the script block like – 

So, I have used the JS API to invoke the cached service which means I am bypassing the limitation and calling the service directly.

Final step : Testing the solution

So, I am done with the cooking, it time to test (taste) the results – 

If I run the human service, it looks like – 

Now, If I provide some service name and hit on the button – 

Wow, I got the service id, and this is what I see in the SysOut logs – 

If I hit the button again, I see the same result as above but nothig in the SysOut logs which means the service has fetched the result from the cache for the provided input.

Now, Let me provide another service name  and hit the button – 

I get a different service id in this case and let me see the SysOut logs – 

I have got another entry in the SysOut logs for this service call. 

If I press the button again with the same input, it gives me the result back but without calling the service. 

So, our solution works well !

I hope this will help developers while developing integration services for fetching kind of static data which change very rarely.

If you are going through this recipe, kindly share your views. Any suggestion, idea, criticism is welcome.