Triggering a change in package

, ,
1

We have a requirement to export the updated packages to CVS automatically by using some webMethod flow/java service. Is there any effective method which triggers the change in a package and export that package to CVS with updated version.

Thanks

2

I believe there is no such automated mechanism exist like this,which you are expecting from a flow/java Service.

Let c if any one have answer for this.

3

As far as answer to your question is concerned, yes, this functionality can be built in webMethods. But will it be worth the effort?

Using webMethods/Java, one can build a solution to zip contents of a directory, ftp/move to some location, run a script (UNIX or Windows) to check the file into any source control…

now, after all this functionality is built, one needs to trigger such a flow service… and you want this to be triggered automatically!!
one such way is to enforce your developers to change the version number of the package whenever they make a change… make this as a requirement for any developer to do, if s/he wants the changes to go through the nightly build…
any change in the version number, reflects a change in the manifest.v3 file… so, now all you need to do is monitor that file for any changes…

BINGO… you have an automated way to check in packages into any source control… rest of the details I will leave to imagination…

But, as I said, make your decision based on time it will take to develop such design versus the benefit!!

Let me know if you have any questions or if I wasn’t clear enough.

Best of Luck.

  • Saurabh
4

"Using webMethods/Java, one can build a solution to zip contents of a directory, ftp/move to some location, run a script (UNIX or Windows) to check the file into any source control… "

Is any body implemented this mechanism in their realtime builds?Will this not throw any pub/sub package errors when migrating?

Thanks,

5

In our dev process - we use a script to call into WM flows that archive the contents of a package. We also update the package version prior to archiving such that it stays in sync with the CVS version number.

6

RMG,

Is any body implemented this mechanism in their realtime builds?

  • Yes. And, in fact, this way you can customize to include only relevant files. Implying remove all the *.bak files, use jcode to build *.frag files etc etc.

Will this not throw any pub/sub package errors when migrating?

  • Nope. In fact, if one finds it easier, you can always move any package or zip it for archive purpose; you dont need to use the webMethods provided functionality.

this is why I always liked IS over ES. This ease-of-use; this building any solution, the only limit being your imagination/time. Its like being more open in nature than ES!

  • Saurabh.
7

Sounds cool,Thanks for the response.

8

“We also update the package version prior to archiving”.
Haithem, can you elaborate a little more on this and how you accomplish this.

Saurabh, u wrote “enforce your developers to change the version number of the package whenever they make a change”. I think it will be not effective, as many changes has to be done and it will be a pain to every developer to change version info every time they make a change.

9

NN: do reconsider what Saurabh said about incrementing the package version. If your developers don’t increment the version number of a package they change, you lose a valuable way to track changes.

Also, if you are using the 6.1 platform, take a look WmDeployer. It seems to do a lot of what is discussed here. There are some issues with it though that I mentioned here:
[url=“wmusers.com”]wmusers.com

I heard people discuss using Deployer from the command line to automatically check in a “Deployer Build” into CVS or other versioning tool.

10

NN,
the only workaround (and it really round :wink: ) is that you write a .sh or .bat file which finds which packages were touched/changed on a daily basis.
Based on that, you can increase the package version numbers in more automated way.

But I guess, this is more pain to implement with lot of problems. Say, what if, developer has not completed his/her changes or dont want to check in those changes yet.

Remember, for any source control to work, it has to be triggered manually. webMethods is no exception to that. You can automate parts of the process, but there needs to be user/developer involvement to either “check in” code or trigger the process to “check in” code.

Just my thoughts,

  • Saurabh.