From ACE 12.0.11.0 the Toolkit palette has been expanded to include 8 new Discovery Input Message Flow nodes:
For the last few mod releases of App Connect Enterprise, and as shown by the sections above, we have rapidly expanded the number of available Discovery Connector message flow nodes - both input nodes to trigger a message flow and also mid-flow request nodes. The design inspiration for these nodes originates from our App Connect Designer tool which can be used for authoring simple flows in our managed cloud offering and our software container offerings. In a similar design style, the ACE 12.0.11.0 Toolkit now provides a new Log message flow node which helps simplify the task of writing log records to Activity Log in the ACE Web UI. The Basic property tab has a Configure button which opens a more detailed configuration page that looks just like the Discovery Connector configuration pages.
After dragging the node from the Toolkit palette onto the message flow canvas, click the Configure button and use the available properties to control the contents of the Activity Log entries that you wish to generate. The graphical editor also lets you take advantage of the JSONata expression language capabilities which were first made available in Toolkit as part of the mapping capability for discovery nodes which was introduced in 12.0.10.0 For more information about JSONata, which itself is an open source technology, check out the website here which also includes a JSONata exerciser. The Log Node configuration panel lets you select a hard-coded value for the Log level of Debug, Info or Error. Alternatively you can choose a Custom... option which will identify the log level dynamically using a field from the data passed into the Log node. There is also a Message detail property which lets you type free-form text that will appear in the log entry. You can supplement this text with values from the data passed into the Log node or details about the flow such as the Flow name shown in the screenshot below. You can also optionally choose to define Custom message fields to be included in the log entry. Any custom message fields that you define will appear as tags in the generated activity log entry:
You can also add Custom message fields from the data coming in to input terminal of the Log message flow node. Adding entries to the Map Inputs property tab's table, before clicking the Configure button on the Basic property tab, informs the message flow node about the structure of data which is expected to be received by the node and lets you easily address fields using the handy JSONata selection windows like the one shown in the picture above.
In this simple example we just display the default settings above as we have no need for data modelled in further schemas. Having saved all your node configuration, deployed the message flow, and sent some data through the flow, the results of the Log node entries in the Activity Log panel of the ACE Web UI will look similar to the screenshot below:
ACE 12.0.11.0 introduces a new type of policy that can be used to help configure the HTTPRequest and HTTPAsyncRequest message flow nodes. The HTTP Request policy can be deployed and referenced from a message flow node to control connection properties at run time. This new type of policy can be created in a Policy Project in the Toolkit and used to influence outbound HTTP connections from a message flow:
You can attach an HTTP Request policy to an HTTPRequest or HTTPAsyncRequest node to control connection properties at run time. The policy is mainly utilised when you require a simple way to define security settings - for example if you want to configure an outbound HTTP connection to use basic authentication of if you wish to use API key credentials which are saved in the App Connect Enterprise vault, or which were defined using the mqsisetdbparms command. The API key location property dropdown can be set to header (as shown in the example above) when passing an API key inside the HTTP request header, or body when passing an API key in a URL-encoded format within the request body.
For many years, the ACE software product has provided generic EmailInput and EmailOutput nodes which enable emails to be automatically sent as part of a message flow. This can be useful for various logging or auditting scenarios. The product also benefits from dedicated message flow nodes that can interact with specific email providers such as the Gmail message flow nodes (Input and Request) and Microsoft Exchange message flow nodes (Input and Request). The generic EmailInput and EmailOutput nodes have long been configurable with credentials that require a Basic Authorization security model to be adopted when communicating with the email server but starting from App Connect Enterprise 12.0.11.0, you can authenticate with an email server by using the OAuth (Open Authorization) standard.
The Email server name property of the message flow node accepts server addresses which are defined with the imap, imaps, pop3 or pop3s transports. The Security identity property of the EmailInput message flow node links to the definition of credentials which are to be used when communicating with the Email server. You can supply these credentials using the mqsicredentials command.
ACE 12.0.11.0 introduces some new connection parameters for exploitation when using the EmailInput and EmailOutput nodes. These parameters (Enable the use of the STARTTLS command and Requires the use of the STARTTLS command) have been added to the required policy types for the two types of message flow node:
- The Email Server type policy for the EmailInput node
- The SMTP Server type policy for the EmailOutput node
The parameters involve commands using StartTLS, a concept that readers may be familiar with from other email clients. It is used to tell the email server that the email client wants to upgrade from an insecure connection to a secure one using TLS or SSL, before issuing any login commands. The pictures below show how you can successfully configure these parameters for an EmailInput node when using OAuth with a Gmail server:
The next picture below shows how you can successfully configure these parameters for an EmailOutput node when using OAuth with a Gmail server:
The examples above are for interaction with a Gmail email server, but you can change these values to be relevant for whichever email server you wish to interact with. The examples above expect the definition of a security identity named acegmailinput for the EmailInput node and acegmailoutput for the EmailOutput node. Here are some example commands for creating the security identities:
mqsicredentials --ext-vault-dir <Your External Directory Vault Directory Location> --ext-vault-key <Your External Directory Vault Password> --create --credential-type email --credential-name acegmailinput --access-token <Your Access Token> --client-id <Your Email ID>mqsicredentials --ext-vault-dir <Your External Directory Vault Directory Location> --ext-vault-key <Your External Directory Vault Password> --create --credential-type smtp --credential-name acegmailoutput --access-token <Your Access Token> --client-id <Your Email ID>
For further information about the new OAuth capabilities, check out the documentation here.
The ACE 12.0.11.0 Web UI includes a useful enhancement which enables you to quickly retrieve from the runtime a BAR file which contains an application that has previously been deployed to your integration server. This feature mirrors equivalent capability which was added to the Toolkit in previous mod releases. This capability can be particularly useful if you have an application deployed to one integration node's integration server and you are keen to quickly create a copy of the application and deploy it to a different server, but you don't have the source files or a built BAR file for the application readily available. This could be through a desire for the speed and simplicity afforded by the use of a web browser, or maybe because you are an administrator and you don't have a Toolkit installation to hand.
Please also bear in mind that there are some limitations surrounding the retrieval of particular older legacy flow formats which are documented in detail here.