Exploring IBM App Connect Enterprise 12.0.9.0
In this article, we take a dive into some of the features of IBM App Connect Enterprise 12.0.9.0 and explore how developers can use them for their integration needs.
·
Join the DZone community and get the full member experience.
Join For FreeWe'll explore five of the features released in IBM App Connect Enterprise 12.0.9.0 and provide a high-level overview of each;
- Toolkit: Retrieving Source Flow.
- Configuring an Integration Server's JRE Version.
- JavaCompute Node Credential Lookups.
- External Directory Vault.
- Scheduler Node.
Toolkit: Retrieving Flow Source
Typically, the developer of a message flow who is using the IBM App Connect Enterprise Toolkit will have access to the source .msgflow file that represents the message flow. This message flow might be saved on the disk system of the developer's local machine as part of the Eclipse Toolkit's workspace, or it might be kept remotely in a version control system.
There are other circumstances where a developer (or a system administrator) might want to understand the flow layout for a message flow when they don't immediately have access to the source message flow file. This could be for a variety of reasons — perhaps because the user wants to quickly understand the behavior of a message flow or infer the route that a message has traveled when passing through a flow.
App Connect Enterprise 12.0.8.0 provided the Toolkit user with a new feature to view the active flow layout of a deployed message flow. This feature has now been further extended and enhanced in this release, App Connect Enterprise 12.0.9.0. The new changes are as follows:
- Support for viewing and retrieving compiled message flows (.cmf): You can now view and retrieve .cmf files into the IBM App Connect Enterprise Toolkit. The .cmf files are automatically converted into .msgflow files when you import them. For more information, see Viewing the active flow layout of a deployed message flow in the IBM App Connect Enterprise Toolkit.
- Support for viewing and retrieving migrated message flows: You can now view and retrieve message flows that have been migrated from previous releases into the IBM App Connect Enterprise Toolkit. The migrated message flows are automatically converted into .msgflow files when you import them. For more information, see Viewing the active flow layout of a deployed message flow in the IBM App Connect Enterprise Toolkit.
- Support for retrieving deployed BAR files: Support has been added for retrieving a BAR file from a deployed application. In a previous release of IBM App Connect Enterprise, support was provided for retrieving resources from within a deployed BAR file. In V12.0.9.0, this support has been extended to enable you to retrieve the entire BAR file so that you can redeploy it to a different integration server. For more information, see Retrieving a deployed BAR file.
- Support for retrieving Java resources used by message flows: Support has been extended for retrieving deployed message flows that use Java. If the resources that you retrieve include a message flow that uses Java, such as a Mapping, Compute, or JavaCompute node, the .jar file that was compiled when the message flow was deployed is imported and added to the application containing the message flow. This enables you to rebuild the application in the IBM App Connect Enterprise Toolkit and deploy it to an integration server. For more information, see Retrieving and importing deployed resources into your workspace.
- Support for importing policies automatically: Support has been extended for retrieving deployed message flows that reference policies. The Retrieve and Import wizard automatically detects which deployed policy projects are referenced by the application, and they are selected in the wizard. When the wizard finishes, the policy projects are imported into the workspace. This enables you to import policies that were migrated from configurable services that were in a previous release of App Connect Enterprise. For more information, see Retrieving and importing deployed resources into your workspace.
Configuring an Integration Server's JRE Version
When you install IBM App Connect Enterprise 12.0.9.0, just like previous releases, the installation brings with it the correct supported version of Java, which the product needs to operate successfully. For ACE 12.0.9.0, this is Java version 1.8.0. However, users now also have the option of separately sourcing and installing an alternate installation of IBM Java 11 and then specifying that a particular independent integration server should use that alternate level of Java. This is done using the ibmint specify jre command, which can be run in an ACE command console session as shown below:
As you can see above, you can use the same command to list the supported versions. With this release, version 11.0.18 is the only supported alternative. In the future, it is likely that the set of supported alternatives will be further expanded. In the above example, the working directory at C:\MyWorkDir has been configured successfully to be associated with version 11.0.18. The output from the command mentions the creation of a YAML file named server.java.yaml. If you open this file, its structure might remind you of the server.components.yaml file, which is created when you optimize an integration server (using the ibmint optimize server command) so that only particular features of the server are turned on. The screenshot below shows the contents of the file:
When the Integration Server is started (configured to point at the same work directory mentioned above), JRE 11.0.18 is used, but various features of the server have been disabled:
In future releases of ACE, we expect that this feature may be extended so that fewer features will be switched off when Java 11 is chosen, and further supported alternate Java versions will be introduced.
JavaCompute Node Credential Lookups
For many releases (since 11.0.0.7), App Connect Enterprise has provided the ability to encrypt and store credentials, which can then be used to access secured resources from a message flow. Credentials that have been defined in the vault are typically referred to using a SecurityIdentity on a message flow node's properties or abstracted away from being stored in the message flow itself, with the SecurityIdentity referenced as a property in a policy.
From the App Connect Enterprise 12.0.9.0, these features have been extended to allow a user's Java code (running inside a JavaCompute node in a deployed message flow) to query and gain access to credentials. This is potentially useful for users who wish to use credentials within their own bespoke logic running in Java and who want to exploit the convenience of having ACE store the credentials safely on their behalf. The example code snippet shown below provides a simple demonstration of how you can access a credential:
By default, this new feature only allows access to credentials that are of the user-defined type. This aspect of behavior can be controlled by a setting in the server.conf.yaml file. The stanza shown below can be edited so that if you want to extend access to also include other credential types, then you may do so:
External Directory Vault
You can configure an App Connect Enterprise vault to symmetrically encrypt and store credentials, which can then be used to access secured resources (from a message flow, for example). You can configure a vault by using the mqsivault command and then use the mqsicredentials command to encrypt credentials and store them in the vault. The ACE vault technology has been around for quite a while (it was initially introduced in 11.0.0.6), but new in the latest 12.0.9.0 release is the concept of an External Directory Vault.
An external directory vault is an App Connect Enterprise vault that can be used by any integration server and can be accessed concurrently by any number of integration servers. The external directory vault is created in a directory that is external to the integration server rather than located in the integration server's work directory. You choose the location in the file system in which to create the vault and then configure each integration server to use it by specifying its unique location.
From App Connect Enterprise 12.0.9.0, you can also exploit this same advance in vault technology from an integration node so that credentials that are stored in the configured external directory vault are available for use by the integration node, the integration node-wide HTTP listener and any integration servers that are managed by the integration node.
The Toolkit has also been enhanced in 12.0.9.0 so that when you create a local integration server within the Toolkit, you have the option of specifying an external directory vault that can be used for storing credentials:
If you choose the option, then the external directory vault will be created within the Toolkit workspace, but by default, it will be placed in a location named TEST_EXT_DIR_VAULT that is separate from the integration server's working directory (which is named TEST_SERVER by default). Once you've supplied a vault key, click the Create Vault button:
The Create Vault button will be replaced with a Test access button:
Clicking Finish will cause the server to be created. The working directory of TEST_SERVER and the external directory vault location of TEST_EXT_DIR_VAULT will be visible in the Independent Resources section of the Application Development view as shown below:
If you are in Toolkit and using any of the Discovery Connector nodes, then you will require a vault to store the credentials for accessing the 3rd party system against which you are running Discovery. If you use an external directory vault, then there is no need to stop the local test server in order to launch the connector discovery process. This is a big usability gain over previous releases.
Scheduler Node
The Scheduler node, new to the product in App Connect Enterprise 12.0.9.0, lets you configure a message flow to run at specified repeating intervals on particular days of the week or based upon a Calendar function. Accordingly, the node properties provide a radio button selection which allows you to choose either a Repeat Interval or Calendar, and when switched between these two options, the properties display will change as shown below:
Repeat Interval
Calendar
The Output Message section of the node properties controls the format of the logical tree, which is propagated downstream out of the Scheduler node.
There are three options:
- Scheduler format: The output from the node provides an output JSON domain message tree, which carries two fields — the currentEventTime and the lastEventTime. The same information is also copied into the LocalEnvironment tree. This behavior mirrors that of the Scheduler node that is provided in the Designer authoring tool of App Connect.
- Timeout notification node format: As its name suggests, this option causes the message tree, which is output from the node, to be in the same style as that of a Timeout notification node. This means that the main message tree simply carries a Property folder (and no message domain body), and the LocalEnvironment tree carries both a Scheduler section and a Timeout section, which has more fields, as shown in the picture below (displaying the output from a Trace node which has been placed downstream of the Scheduler node):
- Message assembly file: This option lets you browse and select a Message assembly file. This file describes the format of the logical tree, which should be propagated downstream each time the node is fired.
Summary
IBM App Connect Enterprise is constantly evolving to support professionals in completing their integration needs. By diving into some of the latest product features and describing concepts, we aim in this article to help you learn more about how to use them to solve your business problems.
Published at DZone with permission of Ben Thompson. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments