Enhancements to the ACE toolkit for developers

In 11.0.0.7, there is now an option to create and start an independent Integration Server from the toolkit. The Integration Explorer view in the toolkit now has an option for creating an independent Integration Server. You can right-click on ‘Integration Servers’ and select ‘Create a local Integration Server’

A wizard will be shown which allows you to specify a name for the Integration Server and configure some ports for commonly used functions. The default name for the Integration Server is TEST_SERVER. If you wish, you may allow the toolkit to find ports that are currently free. This allows you to quickly deploy and test your message flows using a local Integration Server.

• The REST Administration port must be configured so that REST requests can be sent to the Integration Server over HTTP. This port is also used for the Web UI.
• The port for HTTP-based flows is used after the flow has been deployed. The toolkit will only select a port that is currently free at the time when the Integration Server is started. If the port is in use at the time that the flow is deployed, then the flow will not start.
• The JVM debug port is used for debugging message flows. If you do not want to enable the JVM debug port, you can specify zero.

After clicking on ‘Finish’, the server is started and a link is provided to open the ‘console.log’ file which contains the standard out from the Integration Server. The ‘console.log’ is contained in the work directory top level folder.

You may need to change the ports if they are in use when you start the Integration Server. You can change the ports at a later time in the overrides/server.conf.yaml file. If the overrides/server.conf.yaml file is changed, the Integration will need to be stopped and started again.

The work directory is created in the workspace. It can be viewed under ‘Independent Resources’. The work directory name has the same name as the Integration Server.

The port values are written to a server.conf.yaml file in the overrides sub-folder under the work directory. We recommend that any other configuration that is needed is done to the server.conf.yaml file in the overrides sub-folder for clarity.

The console.log can be opened to view output from the Integration Server. If you have a Java Compute node which has debug output using ‘System.out.println’, the output will be visible in console.log.

BIP event messages can be viewed in
/TEST_SERVER/log/integration_server.TEST_SERVER.events.txt in the workspace.

You can start multiple Integration Servers from the toolkit. Each Integration Server must have a unique name and a matching work directory in the workspace. If you attempt to create an Integration Server of the same name, an error will be shown.

If an Integration Server is stopped and the connection is removed, the work directory is not removed. You can create an Integration Server which is using an existing work directory in the workspace if it is not in use. A warning message is shown to indicate that the configuration in the existing work directory will be used.

The toolkit does not do full process management for the locally started Integration Server. If the toolkit is closed, the locally started Integration Server is stopped. However, if the toolkit closes unexpectedly, then the Integration Server may not be stopped. You must take care to stop the Integration Server using OS process management tools if this happens.

An Integration Server is not automatically started when the toolkit is started. It must be manually started. The stop and start menu options for an Integration Server are only available if it was started from the toolkit. If it was started remotely, and a connection was made to it from the toolkit, there is no option to start or stop that Integration Server.

Improvements have also been made when a BAR file is deployed to an Integration Server. On deploying a bar file, you can see what resources have been deployed.

If I change the HttpInput node in my message flow so that the ‘USE HTTPS’ checkbox is selected and deploy without specifying a location for the keystore to use.

I will receive these errors in the Deploy window:

Each error message is distinguishable and can be clearly seen if it is an Information, Warning or Error message. If you click on any error message, the full text is shown in the pane below. In addition, you can click on ‘Copy’ to copy all the deploy messages to a clipboard so that you can share them with a colleague or a System Administrator.

You can paste into a text editor:

Similarly, the dialog is shown if an error occurs when starting a resource. The dialog contains detailed text for each BIP error message. You can also copy the messages to a clipboard and paste into a text editor.

You can enable Service trace or User trace for the Integration Server if you need to check areas of your Integration Solution. For example, if I enable User trace and then put a message through the flow and stop User trace afterwards, I can now check the User trace that was generated. The User trace is located in config/common/log under the work directory. In this example, I can see the lines of ESQL that were executed in the Compute node of my message flow. In addition to starting and stopping trace, you can also start and stop monitoring and statistics for an Integration Server.

The User trace is located in config/common/log under the work directory. In this example, I can see the lines of ESQL that were executed in the Compute node of my message flow.

In addition to starting and stopping trace, you can also start and stop monitoring and statistics for an Integration Server.

The new mqsivault and mqsicredentials commands should normally be used to store and encrypt credentials that are used to access resources from your message flows running on production systems.

While developing your applications, you may want to quickly test aspects of your message flow without wanting to configure a vault and encrypting credentials. For this reason, you may now set your credentials in the server.conf.yaml file. You just need to specify the credential type and credential name under a ServerCredentials section in the server.conf.yaml. In this example, I am setting the username and password to access a DB2 database over JDBC.

I am referencing the credential name from within a JDBC Providers policy.

After changing the server.conf.yaml, the Integration Server must be stopped and started for the configuration changes to be picked up. The Integration Server can now use the credentials when processing messages in a message flow.

A number of enhancements have been made to the toolkit:

• You can now create an independent Integration Server from the toolkit so that you can quickly test your flows without needing to open a command console and use a number of commands.
• A new dialog is shown when deploying a BAR file or starting a deployed resource.
• Options on the Integration Server allow you to enable or disable trace, monitoring and statistics.
• You can set credentials in the server.conf.yaml so that you can quickly test your message flows which are interacting with external resources.

These enhancements make it an improved experience for developers using App Connect Enterprise to develop Integration Solutions.