Hi All,
I’m new here as well as to webMethods. I am using webMethods 10.1. I was wondering if there is a flow service to set the service cache expiry? I’ve set the service Cache results to true and the Cache expire using the Properties of the service. However, I’d like to be able to be able to change the Cache expire without having to change it in the Properties.
Is there a way to do this?
Thanks in advance for your replies/help.
Use the below services at your own risk
wm.server.services:serviceInfo – to get service props
wm.server.services:serviceInfoSet – to set service props
Thanks, I’m trying it out now!
Hi, I didn’t find the services in webmethod 10.5 version. Can you advice where to find this?
Those service are part of the WmRoot package and for security reason it will be set to hide by default.
if you need to view the service from designer you have to set the below watt property
watt.server.ns.hideWmRoot=false
Regards,
Dinesh
Hi @DINESH_J,
Thanks for your prompt response. Can i use those service to reset/set the expiry of the cache? what is the best practice to set expiry on demand based(pro grammatically).
Thanks,
Software AG do not support of using service . You have to use it at your own risk as mentioned previously by @Mahesh_K_Sreenivas
This setting should only be neccessary for the development instance.
on higher instances there is usually no need to have this package visible in Designer.
Regards,
Holger
“Best practice” is a fuzzy term that can mean just about anything. 
For me, the advice for “how to do this” is to avoid using caching unless it is absolutely necessary.
Might I ask why service caching is being used? Hopefully, metrics were gathered and it was determined that response time was such that optimization was necessary and that caching was the way to go. I ask because most of the time I see when caching is discovered (typically by those new to wM IS) people want to try to use it right away – but doing so is usually premature.
The 3 rules of optimization:
1: Don’t.
2. Don’t yet.
3. Profile before optimizing and optimize only what you need.
Service caching is optimization. For most integrations, it is not useful.
My guess is that people want a way to change the cache expiry time for a service “on-demand” or flush the cache because it is sometimes not returning the desired data (data behind the service changed, but the caching is hiding it). This is the main problem with caching and is why it is to be avoided unless absolutely necessary.
I would strongly advise against using those services to change the properties of a service. Instead, edit the service and re-deploy.
Is there any specific reason why you would want to change the settings on those services dynamically? As @reamon indicated, it is best to update the services and re-deploy.
In addition, service results caching does provide optimization in service execution when Data that you need to retrieve is static or can change periodically. In many customer’s implementation this option is utilized to avoid frequent read operations from Database local or remote, fetching data from external providers through REST or Webservices calls.
Regards,
-Kalpesh.
My scenario is that I create a flow service (which will get the JWT from third party service) and need to cached till the token expire. That’s why i need to refresh the cached once new token fetched.
Have you looked @ prefetch option? Prefetch will auto refresh (invoke underlying service) when cache expires.
You should be able to set the cache expire to be just shorter than the expected lifetime of the JWT. The lifetime of the JWT is likely static – always valid for 2 hours (or days or whatever). Set the service cache to be just short of that so that wM IS always views the JWT as expired just before the issuer does. That way you limit the possibility of wM IS thinking the JWT is still valid but the issuer does not. The prefetch might be useful but may be overkill if the JWT is needed just once a day and the JWT expires every 2 hours.
You should not need to dynamically change the cache expire value. That should rarely change and if it does, edit and re-deploy. Annoying, sure but that seems to be less risky than trying to dynamically change service properties using wM services that we’re not supposed to use.
Another approach – do not try to hold on to the token. Just request again each time it is needed. (We do this for a couple of external endpoints. Works fine and doesn’t have the overhead of trying to manage caching.)
Another approach – implement your own “session management” pool that stores tokens. The service that needs to use a token calls to get a stored token. The store service checks if the token has expired. If so, it returns nothing and the caller needs to request a new one, which then gets put to the store.
Agreed. I would offer that it remain off in development as well. Leaving it open will tend to lead some to use WmRoot services when they should not. When you really need to use such a service, the technique is to create an INVOKE step with any service at all. Then in the Properties pane, paste the WmRoot service name you want to use. Move the cursor off that step and then back – you’ll see the inputs and outputs.
This approach discourages “casual” use of the WmRoot services. It makes the dev take an explicit extra step to use, reminding them that it is unusual/not recommended to use such services.
Prefetch option will not meet my expectation cause of expiry will extract from the JWT and that need to be set cache expiry.
Thanks @reamon for giving the detailed information. The challenge I see that if token expiry will dynamic value. And secondly if the toke lifetime decreases from 24 hours to 4 hours then i need to update the service and redeploy it means require a development.
I see another approach that will no development require it’s only update the configuration in IS whenever it needed. Create a cache manager in IS admin and will use the use cache services to put and get the token to/from cache manager.
Ah, creating a cache manager may be a good approach. Didn’t think of that one.
I would again suggest that a good option, which requires no additional setup nor ongoing management, is to not cache the JWT. Just get a new one each time. If this is in support of an automated integration (no user waiting for a response) then the little bit of time used to get the JWT is likely meaningless. Even if there is a user waiting, the time to get a JWT may be negligible.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.