is there a better way to publish hundreds of packages?

We have three IS enviourments and one of them is for developping. Each time, when we update the package, we have to export it and ftp to other IS directories(…/IntegrationServer/replicate/inbound) and publish the package through IE admin page.
But we have hundreds of packages? Is there a better way to do this? And we 've noticed that in IS ,there is a “package” directory for all the packages, can we just copy them into there directly? that would be much easier.
Or is there other better way?
Thanks a lot.


You didn’t mention anything about source code control systems. Appendix H of the 6.x Developer’s Guide discusses how to use a third-party scc system with IS development.

Outside of webMethods, you use scripts to check in the components of your packages to your scc system. You then run similar scripts to check then out on your target system and finally run the JCode utility to recompile java services.

Of course, you can skip the entire source code control system step and just copy your packages to the target system and run JCode. However, that would be unwise as you would have no way of rolling back an accidental change.


Quick question about doing source control. We are using CVS to do source control and Ant/Maven to do the build. We need to know if after checking the code out for a build, do we need to reload the package? Some of the changes in the java services and/or flow or config files could require the package to be reloaded? Do you advise to reload the package or restart the server? In any case, how can we automate the package update (reload the package) or server restart in order to allow Ant/Maven to refresh the runtime information in memory. Thanks in advance for the help!

You could use webMethods Deployer to tranport bunch of packages all at once to different environments.


Yes the wM Deployer could be a very useful to deploy all the packages as full version the first time, then you could deploy only in patches also stating the versions of the release not only to to IS but to Multiple IS’s.


I agree that the Deployer is a good solution, but it requires manual intervention. We are trying to automate it using Ant/Maven and it requires to do the deployment programatically.

I already know who to do the CSV checkout/in stuff, and how to update the packages easily. I also know that for java services it’s required to recompile the source code using the “jcode” utility (using parameters such as: frag, make, and comp).

But, what I need to find out is how to reload a package programatically without requiring someone to manually do that. Any suggestions???

I am quite sure this would help some other folks out there trying to do a decent build process with webMethods.

Thanks in advance!

Deployer can be run in silent or unattended mode after you use its web UI to create the 10 zillion objects to describe deployment sets and targets. However, as far as I know Deployer is completely and totally unaware of version control systems like CVS, Visual SourceSafe, StarTeam, etc. This means that you need to manually check-out from your vcs prior to building the deployment sets manually prior to any type of automated deployment.

IMHO, Deployer is a good fit when you need to deploy to dozens of hundreds of targets, but overkill for only a handful of targets.



despite this thread is quite old, there are new informations:

Deployer can select the artifacts from a source IS for runtime based deployment.

Meanwhile with the introduction of Asset Build Environment there is a repository based deployment possible.
But this not able for all asset types especially when they have database parts like process models.

I did not check the features of wM 10.x or CommandCentral yet.


It might be that the repository based deployment can’t handle all the asset types possible with the runtime based deployment, but it can easily deploy process models. We do it successfully for a quite long time already.

I’d very much like to know how to deploy “server wide” configs via repo based deployment (e.g. file access configuration, SFTP aliases etc), but that would be the topic of a separate thread.

I just wrote this to encourage you to use the repo based deployment as it has, IMO, some advantages over the runtime based one.


thanks for sharing your opinion about this.

We will check this during our upcoming migration to 10.x in the future.

For the time being we are quite familiar with Runtime-based deployments currently.