We will be migrating our WM installs to different machines. We have quite a number of scheduled services and to avoid having to manually go in and create on the new box we’d like to copy the existing schedule which will not change. Is this saved in some file somewhere that we can copy??? Thanks in advance…
There are a number of methods under .WmPublic/pub/schedulers
You should be able to get an array of TaskIDs and then loop through these to obtain all of the information required to reinstantiate the schedulers. Play around with some of the methods in pub.scheduler:
pub.scheduler:getTaskIDs - obtain a list of all schedulers by task IDs.
pub.sheduler:getTaskInfo - This will provide you with all of the info that IS knows about the scheduler. Store this information in a flat file or an xml file that can be loaded into the new instance.
pub.scheduler:addRepeatingTask (or complex task or one time task) - use this to add a scheduler to the new instance using the information stored in the flat/xml file.
Ideally, using your finely honed IS skills, you should be able to figure this out in about 5 minutes by opening up the Built-in services guide.
Ray
thanks for that information, i knew there had to be something… may take a little effort but its reusable and there definitely is potential to use this as shareware for WMUsers… this is on my list for sure…
I didn’t have access to this info previously, so here’s a little more help in the form of an XML structure to store the data in:
Hope this helps.
Ray
Jim Ray as usual gave the good detailed approach but I think an easy way to move your schedules is to copy jobs.cnf file from IS/config directory this xml file holds your scheduled job info. Same way you can move users.cnf file to avoid rebuilding all your user id’s
Igor,
You always take the easy way out. I’ve made a note of this!
Actually, I’ve made a note of the file movement as you have specified. In my case, the users are many times different, but the schedulers are not. Thanks, I learned something!
Ray
On this same note, here’s we’re trying to do. We have three servers now that we use, we wish to make exact replcas of the three environments on three new servers. Nothing will change except for the IP’s of the servers, the schedules should match, the users, ports, remote servers, etc etc etc shold be identical…
Is this as simple as copying the entire config directory to the new server and restarting??? Any special considerations to take note of?? Does copying the server.cnf file cause problems on the new machine???
Thanks in advance
I don’t think it’s that simple - for example there is a config file under the packages/WmRoot/config directory called listeners.cnf. On *nix boxes, you might be able to copy the entire webMethods directory structure, edit the server.sh file for base directory entries, start each one individually and change the ip address you bind the ports to.
At one point we tried to MOVE an entire directory to a new location, then I wasn’t able to do a complete uninstall later on because some temp files were missing or screwed up somehow.
I thought I heard something at the wm conference about wm6.0 having some better facilities for making images.
Will
I wont be copying entire directory stuctures, I’m only interested in copying the CNF files that are needed. Here are my thoughts please confirm my understanding:
Files 2B copied
users.cnf - All user info
remote.cnf - All remote alias info
port.cnf - All port info
jobs.cnf - All scheduled service info
acls.cnf - All ACL info
acls_sm.cnf - All ACL info(what does this file exactly do again?)
Obviously from/to the config directory…
Remember that the new server is an exact replica of the older one except for the IP, everything else should be identical.
Would I need to copy anything else?? I’m hesitant to copy the server.cnf file and I think I’ll make those changes manually. Let me know your thoughts. Tx in advance
acls_sm.cnf contains the mapping of ACL assignments to folders and namespace objects, this is why ACL assignments are not replicated as part of a Package replication.
-
make sure the target IS server is down
-
edit the file, to change all occurrences of the previous hostname to the new hostname (yes, the hostname is in the jobs.cnf in lots of places) if you don’t do this, none of your tasks will not show up
-
if you are using IS clustering and want to move this to some other IS,
then be sure to find occurrences where it says to schedule it in the cluster and change it from yes to no (or true to false - can’t remember), so that when you bring it up the first time, it will be a local job. Then you can use IS Server Admin to change it to schedule it in the cluster -
make sure that the IS users who the jobs are scheduled to run under do
exist