Hi All,
Please help me to know the command to export, import and install packages from command line. I know it very well the usual way, but do not know it thro’ command line. I am using webMethods 6.1. Hope it is same for all versions.
Please help me…!! It is very urgent.
The solution you propose is not supported in the event that you have an issue.
With that out of the way, there are a few ways to accomplish this.
We wrote a stand alone java service that saved packages, installed them, etc. from the command line. It required the use of properties files that set environment variables for transferring code between environment. It was originally written using 4.02 client API.
I have used it for 6.01, but not all of the functionality exists. It took about 2 weeks for the java developer to finish the job from start to finish.
You can call wm.server.packages:packageInstall from your java program to install the package.
Again, this is not supported and you are not guaranteed that the API will be available to you in the future.
If the package has locked elements, there will be no way for the system to communicate this to you. It will not install if there are locked elements, so you will want to unlock everything programatically prior to installing the package.
If I were you, I would stick to the supplied interfaces until you get to a level of HIGH comfort with the platform.
There isn’t an out-of-the-box solution for installing a package onto an Integration Server from the command line.
The out-of-the-box solution is to use the IS Admin pages to publish a release from the source server, subscribe to it from the target server and then manually use the Admin tool’s “Install Inbound Releases” function to activate it.
However, you should be able to use Developer’s Tools->Generate Code function to generate a simple java client that invokes the pub.packages:installPackage built-in service that can be run from the command line to install a ZIP file that you have previously copied to the target server’s \inbound folder.
I suggest that you modify the generated Java file to accept the servername, username, password, Zip file name, and activateOnInstall flag from the command line (or leave them hardcoded).
Once you can install a new release from the command line, you might consider writing a shell script or batch file that accepts a release name and target server name. The script would copy your file to the appropriate server’s \inbound folder and then call the installPackage client to install and activate it.
The “webMethods Integration Server Built-In Services Reference Version 6.1” document contained in the “IntegrationServerBISReference.PDF” in your Developer’s \doc folder discusses the services in the pub.packages folder.
Thanks for the prompt reply. I am writing code which uses the installPackage Service. It is all because we are using Ant Scripts to automate the process.
Thank you very much for your help.
Hello Mark,
I have a question about using Sherry’s requirement. Don’t you lose all the version/history capability info that you get when you publish/subscribe a package to another server the usual way and then lose this by using the “command line” process???
That is a great question for which I don’t have an answer. If you created a patch release from the source server and then used the command line option to install it on the new server, I think you might retain the version / history information, but you would need to test this assertion.
Another approach that some of my clients have used is the following:
Check all of the files that make up the package into your company’s source code control system using the vendor’s command line tools. Scripts can be written to automate this so that only changed files are checked in for the desired IS package. []Use the source code control system’s command line tools to check out the components of the package onto the file system of the target Integration Server. Scripts again can help automate this. []Use the webMethods JCode utility to reassemble and compile java services
This approach probably takes more work from a couple of perspectives:
You have to implement a process in which developer’s consistently check their code into the source code control system. [*]You probably will spend more time writing and fine tuning your scripts to automate the delta comparison, check-in, check-out and JCode processes.
The payoff comes from always having your IS package components in a source code control system so that, in theory, you can always revert to a previous build or version in the event of a server failure or deployment error.
It is good that there are some examples of version control systems usage exists. I had posted one question related to that some time back but did not get the answer to my satisfaction.
What I am looking for is that if it is possible to actually check-in the source files of a package/service (as the webMethods documents claim), what exactly should the user permissions be (for the OS user that runs IS the user in webMethods and the user that checks in/out into version control). Basically the interplay between making the files read only and allowing to make changes through developer is not understood/documented.
I tried to make files read only to test the check in situation but the system lock is not displayed ever in developer and I could change the services despite the read only permissions. Now, That I think was because the root was being used to run IS. However if I use any other user to run IS then what minimum permissions are required on the services files to enable successful running of services and yet keep them locked of the webMethods developer users.
Hi Mark,
I clicked on the link build.xml. But It took me to a page where it said “We’re sorry, the Web page you are looking for cannot be found.” :). Is that build.xml available? If so, Could you please post it here.