Caching in flow services

Overview

Caching is an optimization feature that can improve the performance of integrations. Service caching operates according to the input signature of the enabled service. When caching is enabled, the service result is stored by using the input signature values as the key. If the service defines an output signature, the fields that are included in the output signature are cached.

During subsequent executions of the service with the same input, the cached entry in the service result cache is retrieved. Later, the cached output fields are then merged with the input pipeline and returned to the client rather than starting the flow service again.

Caching can significantly improve response time of flow services. For example, flow services that retrieve information from busy data sources such as high-traffic commercial web servers might benefit from caching.

When are cached results returned?

When you enable caching for a flow service, webMethods Integration manages the cached results differently, depending on whether the integration has input parameters. Having input parameters allows the cache to return results that match specific inputs.

When a cached flow service has input parameters, at run time webMethods Integration scopes the pipeline down to only the declared input parameters of the flow service. webMethods Integration compares the scoped-down inputs to the previously stored copy of the inputs. If a cached entry exists with input parameters that have the same values, webMethods Integration returns the cached results from the previous invocation.

When a cached flow service does not have input parameters (for example, date or time) and previous results do not exist in the cache, at run time webMethods Integration runs the service and stores the results. On the next run, it returns the stored result instead of running the service again until the cache expires.

Points to note

• If a cached integration input signature includes a Document Reference or Document Reference List variable and the referenced document type changes or is modified, you must reset the service cache. If you do not reset it, webMethods Integration uses the old, cached input parameters at run time until the cached results expire. You can reset the cache from the Integrations page.

• If multiple webMethods Integration servers are available, then the cache is available in all servers and the cache behavior is independent. The caches are not shared between servers. For example, if you have run an integration in Server 1, then Server 1 runs the integration and caches the results. Next time if you have run the same integration with same input values on Server 2, then Server 2 runs the integration and caches the results.

• The default cache size for webMethods Integration is 10K elements.

• Cache settings are not stored in version history.

• Cache settings are not saved when you perform these actions:

  • Clone
  • Import
  • Publish-Deploy you must manually enable the cache settings.

• If a tenant is associated with multiple runtime servers, then the cached flow service is run at least once in each server to cache the results in that server. For example, assume that a tenant is configured with two runtime servers and a flow service is configured to be cached for an hour. When this flow service is run for every minute, in this case the flow service is listed twice under the Flow services executions table in Monitor for each hour because the flow service must run on both runtime servers at least once to cache the results.

Types of flow services to cache

While caching the flow service results can improve performance, not all flow services must be cached. Never cache the flow services if the cached results might be incorrect for subsequent invocations or if the flow service performs tasks that must be run each time the flow service is started. The following are guidelines for you to consider when determining whether to cache the results for a flow service.

Flow services suited for caching

• Flow services that require no state information. If a service does not depend on state information from an earlier transaction in the client’s session, you can cache its results.
• Flow services that retrieve data from data sources that are updated infrequently. Flow services whose sources are updated on a daily, weekly, or monthly basis are good for caching.
• Flow services that are started frequently with the same set of inputs. If a flow service is frequently started by clients that use the same input values, it is beneficial to cache the results.

Flow services not suited for caching

• Flow services that perform required processing. Some flow services contain actions that must be processed each time that a client starts it. For example, if a flow service contains accounting logic to perform charge back and you cache the results, the server does not run the flow service, so the flow service does not perform charge back for the subsequent invocations of the service.

• Flow services that require state information. Do not cache flow services that require state information from an earlier transaction, particularly information that identifies the client that started it. For example, you do not want to cache a flow service that produced a price list for office equipment if the prices in the list vary depending on the client who initially connects to the data source.

• Flow services that retrieve information from frequently updated sources. If a flow service retrieves data from a data source that is updated frequently, the cached results can become outdated. Do not cache flow services that retrieve information from sources that are updated in real-time or near real-time, such as stock quote systems or transactional databases.

• Flow services that are started with unique inputs. If a flow service manages many unique inputs and few repeated requests, you gain little by caching the results. You might even degrade server performance by quickly consuming large amounts of memory.