If you build it, it will run!
MattLuczkowiak 120000P9G8 Comments (4) Visits (11485)
If you build it, it will run!!!
by Matt Luczkowiak from WebSphere Process Server Support.
This blog entry is meant to briefly touch on the various ways that our customers can build their newly developed projects in order to deploy to their production environment and start getting their full use. The WebSphere Process Server team realized that not every company will have the same strategy in place to build and deploy their applications and as a result has provided multiple ways to accomplish this task, using various tools.
The first way to get your content built and published for use is done through the WebSphere Integration Developer (WID) tool. Most everyone should be familiar with this tool as it is the primary way to start developing your WebSphere Process Server modules in the first place. Once all the logic has been put into the module and you are ready to deploy, WebSphere Integration Developer provides a couple methods to do this. The most common way this is done is by either enabling the "Build Automatically" option in WebSphere Integration Developer, or by manually issuing the Build command when you are ready to let the tooling generate all the associated projects that make your WebSphere Process Server module into a deployable J2EE EAR file. If you happen to be using the test environment from within WebSphere Integration Developer, or have added a server to the server configuration in WebSphere Integration Developer, you may then use the "Add and Remove Projects" option to publish this to the server. What this actually does is package your modules into an EAR file and deploy it to the server for you. Once deployed, the application is then started and is available for use. Again, this method is extremely useful when developing and testing out applications quickly.
The WebSphere Process Server team does recognize that many companies have different departments for development of applications and for deployment and administering of applications. For this reason, there are a couple additional options in which an application can be built and deployed, without requiring direct access to a WebSphere Integration Developer instance.
The second build method falls into this category and is done via a script called serviceDeploy. This script can be found in the bin directory of any WebSphere Process Server profile. This script takes an archive as an input. Commonly, this can be a Project Interchange file exported from the developer's WebSphere Integration Developer instance. When the script is run, it will take in this archive and generate a deployable EAR file for the server. Once this EAR file is available, it can then be deployed via the methods already mentioned. This method can be helpful if the development is done using a source control system that the files are checked into as the files can simply be checked out from the system and archived into a file to use with this serviceDeploy command.
The third way to build is using ANT scripting. Since it was seen that many companies already have scripting environment set up to automate a lot of the build process, WebSphere Process Server has enabled the option to build WebSphere Process Server projects this way as well. We have introduced a batch file called runAntWid which can run ANT scripts and has some ANT tasks itself that are specific to WebSphere Process Server projects. This is another way to automate builds and checkouts from source control systems.
An important thing to note when attempting to build or when planning a build is that since the tools are all from different component areas of the product, they do sometimes have differences in their functioning. For instance, in some cases the validators that run when issuing a build using WebSphere Integration Developer to build may be a little more tolerant than the validators used when building with serviceDeploy. Of course, there are options to pass in to the various builders to bypass such things, but it is important to be aware that they may not always be identical in their execution. There is an effort to bring these various methods to a common ground where they do function the same unless explicitly told to do differently, though this is an ongoing effort. We in WebSphere Process Server support welcome any comments or suggestions for improvement in this space. However, if you are in a crunch, I would suggest to quickly try out one of the other build and deploy methods if the one you use seems to have some issues. It may just be enough to at least get your application up and running so you don't have to hold up business.
Here are a few links that could be useful when building your projects:
Add and Remove Projects
Using ANT scripts