Scope of the Service Cache

Maybe I’m just not understanding this properly, but I thought if I enabled caching on a service it would return just the cached response from that service. Recently, we noticed some very strange results coming from our services and this seems to have been related to caching (since it started when I turned caching on for some services). It looks like the entire pipeline may be getting returned from cache, not just the service output. Has anyone seen anything like this?

When you enable caching for a service, apparently the entire pipeline is stored and returned and not just the input/output of the called service. This is the normal behaviour of the cached service as per the webMethods documentation, though this is not a desirable way.

So please use caution when enabling caching

We saw the same caching behaviour: the whole pipeline was stored and returned that overrode current run time pipeline if the caching feature were checked.

OK, thanks for the confirmations. I was beginning to think I was losing it :-). I can see how that might work out well for top-level services, but we have lots of utilities and things where we’d like to cache just the output of that particular service. Well, off to the Wish List I go. Thanks again.

Have you tried scoping the pipeline before executing the services? This ensures that only the data contained in the document are passed into the service execution; reducing the size of the pipeline cached as a result of the service invocation.

That sounds like an excellent suggestion Eduardo! I haven’t tried that yet, but I certainly will. I’ll let you know how it works out.

Here is something I do normally to make caching work. I usually wrap the service that I want to cache within a Java service. The java service can explicitly send only the required data as inputs to the cached serviced as opposed to exposing the entire pipeline when called within a flow. Note that the wrapper java service is not marked as a cached service in the setting.

This works well without messing up the pipeline of the output of the cached service. Any more info, please let me know.

Interesting approach Manohar. I wonder if invoking the service as a transformer would accomplish the same thing? If anyone has done it, or tries it, please let us know.

Rob, that was an interesting tip. I didnt know the service called within a transformer restricts the pipeline data. So, this actually aids my approach without having to write a wrapper Java service.

The Cache test I performed now works using the Transformer step.

Awesome! Thanks for testing and sharing that!

That’s great news guys, thanks! I should note one potential caveat, however. Since Transformers can’t loop over list elements this solution may not be applicable in all cases. I’m going to try to see where it fits my needs with this in mind. Thanks again.

“Since Transformers can’t loop over list elements…”

Can you elaborate on this? A transformer can be used in a loop. A transformer (a service) can use a loop. Is there a specific scenario you’re referring to?


Even I do also observed this type of behaviour “Transformers can’t loop over list elements” but strange thing is some times it works and some times i will get the exception inside the loop if i place a transformer and my solution is removing the transformer and invoke a service directly in place of that…But i haven’t able to dig more on this problem…

And I am curious to know the reason…


Oh good, it’s not just me! :slight_smile: Yes, I was referring to a particular exception I see from time to time when I attempt such a thing. I took the exception for it’s word and didn’t bother looking into it, so I unfortunately can’t elaborate. My solution was also to invoke the service normally (not as a transformer). Any further insights would certainly be appreciated.

Good to know about this bug. Thanks for the info!!

The problem with using transformers in a loop must have been fixed in 6.1. I’m looping over a list of common segments for EDI. In the loop I branch on the type of segment (ST, BIG, etc). I put each call to the flow services that perform the mapping for each segment into a transformer. One transformer per map step. The performance increased dramatically and I haven’t had any errors. I ran a test for 10 trading partners as fast as I could kick them off and had no errors.
Have you had errors with this in version 6.1?