I have a question if the following scenario is possible in webMethods.

I have a webMethods developoer service flow which always runs and caches the configuration parameters.
Now, if the need be to change the configuration parameters, can we do it from a separate service flow.
To elaborate more - one primary service will always run in the memory with the initial configuration parameters taken while it started. Now, can I change the value of some of its pipeline varibales from another service.

N.B:- The key here is I dont want to restart the service with changed config parameters rather I want to achieve it dynamically while the primary service is still running.

Can you please help me out.

“…which always runs…”

What does this mean, exactly? Implied in your comment “restart the service” is that the service is running–is that really the case?

Where does the service get the values that are cached?

It seems that you may misunderstand how IS service caching works. Can you elaborate?

Hi reamon,

As always thanks for reply.
Let me elaborate …
There is a flow service which reads the configuration file once while startup and keeps on running in a loop (this loop is defined after the config is read) and does its job. Thus it always retains the parameters read from configuration file in the pipeline until it starts up next time.

Now, if I need to change some of these parameters dynamically (depending on certain situation) without stopping this flow service, what should I do?

N.B:- I was just thinking we can make use of savePipeline and restorepipeLine service (which saves the piepline in memory) with the same key.

Please let me know if I m clear. Thanks.

N definitely I will post back to this great forum if I get a solution on this.

salman

What is the loop doing?

How does that service read the configuration file? Is it doing the work itself (e.g. getFile, etc.) or calling another service?

Salman,

How are the configuration parameters being read into memory.
Arent they being stored in a java.util.Properties object

Pending answers on the loop question and the forever-running service, here are some thoughts:

• Create a service that does nothing but reads the config file and returns the config vars (in an IS doc or as separate vars).

• Configure this service to be cached.

• Call this service from your “forever running” service. Every loop. Since the service results are cached, the service won’t actually be run. IS will simply put the results into the pipeline for the forever service to use.

• You can set a timeout for the caching, so that the cached results will be cleared every N minutes/seconds. You can also force a clear of the cache using IS Administrator. You can also clear the cache by calling the same service that IS Administrator uses. This will cause the config reading service to reload the config file and return the newest settings.

I would encourage avoiding trying to use shared memory or trying to manipulate the pipeline of another session/thread. The caching facilities should do what you’re looking for.

Hi,

Thanks a lot reply.

I will explain in more detail now.
We have 2 URLs of vendor where we need to do HTTP post from webMethods. One URL is primary and another being secondary.
Now, my intention is - while starting up the main flow (to process the data and post it to vendor) , it will read the config file once and it will get the both URLS in pipeline.
Now, the flow will start looping - it will get the message from source, the n it will post it to primary URL then.
Once the primary server goes down, we need to replace the URL with the secondary one.
Now, our intention is to check if the server is up from a different service and provide the correct URL to the main flow dynamically. SO that, when the message is posted from the main flow - it gets posted successfully.

Now, we could have done a PING step before each post but this is being realtime transaction, we dont want to do it.

Create a service that the ping service calls to store the “UseSecondary” flag somewhere (lots of choices on doing this–savePipeline probably not the best but maybe it would work okay).

Create another service, in the same package as the first, that returns the value of the flag. Be sure the implementation is thread safe.

In your infinite loop service, call the 2nd service above. Based on the returned value, use the appropriate URL.

Another approach that might work: in the infinite loop service, have it keep track of which URL it should use. When one URL fails, switch to using the other one. Keep using that until that one fails, then switch back.