The following list provides best practices for iWay Integration Applications (iIAs) and their advantages.
On a development server, an application should send email to the developer, while on a production server, an application should send email to production support. Using an iIA, a Production Template can be used to set an email special register to production.support@ibi.com, while the Development Template can set this special register to developer@ibi.com.
In this scenario, a user has an iIT project containing a channel, two process flows, and a Transform component. They are all part of an application, which the user wants to build and deploy to a development server.
The user can create an iWay Application Archive (iAA) from the iIT project. This creates an application archive file in the iIT project with all of the default deployment properties pre-defined in the project. If there is a name collision or an unresolved dependency, the build will fail.
Another option for building an iAA is to run an iWay Ant task and point it to the iIT project location. This approach allows building iAAs without any user interaction.
In this scenario, a user selects existing channels and process flows from the iWay Registry, builds an iWay Application Archive (iAA) and then (optionally) creates a new Template. Finally, the user deploys the iIA by combining an iAA with a Template. The iIA can be started from the command line, just like any other iWay server configuration.
In this scenario, a pre-built iWay Application Archive (iAA) is stored in an artifact repository or in a source management system. A user wants to deploy this iAA to multiple servers. The shell script for this use case checks the iAA out of the artifact repository, transfers the file to each server, opens a secure shell connection to each remote server and executes deploy and start application commands using the iWay Ant extension.
| iWay Software |