Global Variables shared across servicesflows

Guys/Girls

I’ve been searching primarily here on how to setup a truly global variable. A variable that can be shared across services/flows.
I want to be able to modify the variable as well.

Of course I could set something up a Db Table, but I was hoping that this was more fundamental inside the product.

Any ideas or am I missing something fundamental?

thanks,

tim wiley()

Using concept called create a new Specification on File/new menu tab(near to creat new Flowservice,DocumentType…)inside the IS6.01 Developer tool.

Using this we have to define a new specification containing all necessary fields,records ,create once and use it globally across all the services in the pipe.

HTH.

Tim,

You can use a repository of the webMethods. There are good amount of services in pub.Storage where you can read and modify the varibales.

HTH

Uday

Specifications are for something else RMG…for a consistent interface to a flow service. It has nothing to do with a using a global variable.

Anyways, you can use a java service to make a static variable which will be available across all flows, but it’ll be in memory and will get wiped when the server goes down. So you could create a startup service which would load the constants at startup time.

Guys,
Appreciate all the help… Uday I can’t believe I overlooked the Storage aspect of WebMethods… Not much info on this in the documentation I have. I am actually using Sap Business Connector( WebMethods v4 ).

I have got the storage thing working in a matter of minutes… I learn something new about this product all the time. For some reason i was thinking the storage functions required allot of backend preparation. Boy was I wrong.

Thanks again for the help Uday, I certainly appreciate it.

Kristi,
Thanks as well. I was thinking about doing what you mentioned or a db table lookup but I think the storage routines are a natural place for this type of functionality.

thanks,

tim wiley()

Tim,

Anything can be global in webMethods land - unless you take pains to limit the scope of a variable - or drop it - or clean up etc…

If you know a variable is going to be in the pipeline - put it in the INPUT pipeline of your flow and map it to the desired target.

I have used the repository for this purpose as suggested by Uday - and I believe Ray Moser may have written an ezine about this approach.

There is a risk with using the repository - as it is used heavily by the IS server - especially in clustering - if you read the clustering docs - they recommend against using it. I think its a bit awkward for this kind of use - as you have to register a store before you can use it - so depending on your requirements - you may have to consider cleaning up the store as well. Furthermore - this amounts to storing data in a database - so performance takes a hit over just keeping a value in memory. Again - depends on your application - if your flow logic requires many hits to the store - the hit will be more expensive.

You can create your own “storage” flow using a hashmap (or whatever collection is appropriate). You will probably end up writing a “get” and “put” flow and away you go. May be a little more readable than declaring values in the input pipeline.

As is always the case with webmethods - you have to keep in mind that the design time view you have in developer does not tell you the full picture - the pipeline usually has way more stuff in it than you can view in design time.

Pipeline is not global across sessions though right? I thought each session gets its own pipeline. I know all variables within the pipeline are global to that process unless you scope them out, but they aren’t shared across services started via another session.

I hope I’m not totally off base here on this, because I’ve written tons of flows that get called in parallel and none of them have confused variables yet…

Personally I’m afraid of the repository. You have to worry about deadlocks, the corruption of the file based repository system, figuring out what’s actually in the repository (over time you could be leaving extra junk in there), etc.

You could have an “initConstants” flow where you either hardcode the constants and have all the other flows call this service to obtain the constants, or move the constants into a java properties file and load them at startup. My vote is NOT to use the repository from a couple years of painful experiences.

You are correct that each session gets its own pipeline. No worries!

When I answered your original post - I wasn’t thinking across sessions.

To accomplish this - you will have to persist the value somehow.

I’m with Will on this one - I would stay away from the repository.

But - since you mentioned you will need to modify the value - concurrancy will be an issue.

Haithem

Hi Haithem. You wrote:
“There is a risk with using the repository - as it is used heavily by the IS server - especially in clustering - if you read the clustering docs - they recommend against using it.”

Could you comment a bit more on complications with using the repository in a clustered environment?

The PDF document on Clustering that is in the IS_Server/doc directory didn’t have many negative comments. Is there something about this we can download from Advantage?

Cheers!
Sonam

Yes the flow constant or the java init would be ok… except Like I said I occasionally have to modify these values and unfortunately the flow method will only allow static constants.

Has anyone truly corrupted the repository and under what circumstance, because what I’m talking about is not high concurrency. We may have one or 2 writes over a period of days to 1 variable and all of the other time reading the value of this variable.

This is quite common in all web servers having system level variables that all sessions can reference in code.

Unless people have experienced severe predictable problems with using the storage I’m going to go ahead. This server gets nightly backups. So restoring this thing is a piece of cake since its just one directory. But if you guys are saying this thing will corrupt on low usage and its guaranteed then I guess I will have to go back to using a remote database to hold my variables.

Also… just a thought but would the Administrator utility use the same storage routines to modify its own parameters.

So when I make config changes to the server aren’t we under the same risk of corrupting the repository. I mean we could be adding users or changing passwords right and corrupt the repository.

Anyhow this was just a thought about the storage routine stability.

FWIW, we were using the file-based repository for clustering in a development environment and it got corrupted when our disk filled up from unpurged log files. Support of course recommended we not use the file-based repository for production clustering, but the database approach instead.

Re: the Administrative settings, many of the settings you’d configure as an Administrator are stored in the server.cnf file, not in the repository. I’m not sure about usernames, passwords, ACLs, etc., though.

Personally, I’d store the global values in a config file somewhere and write a couple of Quick services to get/set them.

Sonam - Regarding the Clustering Docs:

The section I was referring to is Appendix A of the document page 78. There they express concerns over “using the repository for large volumes of data storage or permanently archiving such records”.

It sounds a lot less negative now as I re-read it.

I guess my impressions have been formed from having to rebuild the repository a few times due to corruption.

It still leaves me with the sense that the repository is not intended for “programmer” use.

No doubt, the pub.storage flows will do the job - and they did put the flows in the WmPublic package

Thanks Haithem! I’m a bit scared of using the repository myself.

You might know this already, but in case you have TN, its a good idea to run wm.tn.enumerate:deleteQueryResults as a weekly scheduled service so that TN’s query cache is deleted from the repository.

What does the WM Integration Server 4.6 Repository actually do. Does it save operational data? Is it recommended to use it in a production enviroment, even if I am not going to use clustering?
It would be great if somebody could advise me on production guidelines, especially with regard to the above mentioned question.
Thanks
DJ

DJ.
The repository allows you to store variables global to all applications/services running on the server. If you have many process or threads that need common information but you don’t want to have to hard code these variables into each service, then this is your answer.

You can create your own repositories to store different types of information for different applications. You can lock and release variables if they get updated when your services run, so multiple services can have access to the variables without contingency issues.

Is it stable? Very, I have several processes performing infinite loops and checking for files across the United states. This was to replace another product. Its controlled via a web interface. Each process gets its configuration information from a database, but there is some common stuff that i lookup in the repository.

So if you don’t want to use a DB for a repository the native one in webMethods will work fine for small amounts of lookup/configuration information.

Thanks Tim,
So the repository won’t help with the tuning of the integration server? In other words help services execute quicker or more robust? It just stores information that you might use in services in a global sense? You don’t have to reply if I am correct in these statements.
Thanks again

I am trying to implement a global Collection of key-value pairs that will be used by several of my mapping (flow) services as a lookup for data transformation. I would like to initialize this object from the database at server startup. I will not need to modify any of these values within webMethods. The idea is to save the database read time, considering that this data will remain relatively static.

After reading this thread I see that some of you have advised against the use of the repository for similar things. In any case the repository will not serve my purpose since it locks an element when you “get” it.

Will Kriski has also talked about “a java service to make a static variable which will be available across all flows” above.

Could someone “please” suggest a solution to this requirement.

Thanks.