Fix pack 6 introduces the ability for App Connect Enterprise to use an LDAP server to control the authorization of users executing administrative actions against an ACE integration node or independent integration server. Fix pack 4 has previously provided for authentication using LDAP, but this latest fix pack builds on top of this to apply authorization queries to the LDAP authenticated users.

Your LDAP users must belong to one or more LDAP groups, or have one or more LDAP attributes that map to roles in App Connect Enterprise, so that ACE can decide on the appropriate access privileges to provide. Roles in App Connect Enterprise have read, write, or execute permissions for objects in integration nodes or independent integration servers (which are not managed by an integration node). You can configure the authorization by setting properties in the node.conf.yaml file for the integration node, or the server.conf.yaml file for the integration server. There are flexible options for how to configure the LDAP authorization:

• Authorize a single LDAP group to have a role in App Connect Enterprise.
• Authorize multiple LDAP groups to have roles in App Connect Enterprise.
• Authorize an LDAP authenticated user’s LDAP attributes to have a role in App Connect Enterprise.

Given the high degree of flexibility in the configuration of LDAP authorization, at first it can be quite confusing to understand all of the available options. There is a Knowledge Center page which goes into the details, but to help describe how things work, below you will find a simple worked example. This example involves an LDAP server which has been configured with four users:

• Ben Thompson: cn=Ben Thompson,dc=example,dc=com
• Trevor Dolby: cn=Trevor Dolby,dc=example,dc=com
• Graham Haxby: cn=Graham Haxby,dc=example,dc=com
• Martin Boag: cn=Martin Boag,dc=example,dc=com

Each of these user records, has an attribute ou. Ben and Trevor have a value of ou = businessgroup1, where as both Graham and Martin have a value of ou = businessgroup2. Ben’s record and Graham’s record are shown below as examples, with the ou attribute highlighted with a red box:

The screenshot below shows the server.conf.yaml file which is used to configure an independent integration server:

Note the ldap authorization search URL in line 66, which has been set to ldap://ibmexample1:10389/dc=example,dc=com?ou?sub?(cn={{username}}). Breaking this apart into sections, this URL is interpreted as follows:

• ibmexample1 is the hostname of the LDAP server
• 10389 is the port number of the LDAP server
• dc=example,dc=com is the baseDN (Distinguished name)
• ?ou is the attr-name
• ?sub indicates a subset of the LDAP tree structure is to be searched
• cn={{username}} is the filter expression

Lower down the server.conf.yaml file, lines 73 and 74 provide the mapping between the value located from the attribute ou of the logged-in user’s record, and the ACE role. Two roles are defined – viewRole which only has read privileges (line 79) and adminRole which has all privileges (line 80)

The culmination of these settings is such that when Ben or Trevor log in, being members of businessgroup1, they are assigned adminRole’s complete set of all privileges. In contrast, when Graham or Martin log in, being members of businessgroup2, they are assigned viewRole. As a result of these privileges, once logged in, should Ben or Trevor attempt to stop a deployed application, they would see a success message as shown below:

Should Graham or Martin log in, and attempt the same action, they would receive an exception as shown below:

As part of standard operational practice, App Connect Enterprise message flows need to connect and exchange data with secured resources and systems. This fix pack introduces a new feature which makes it easy to encrypt the credentials which are used by independent integration servers for making these connections. The features discussed here are only currently exposed for independent integration servers, but we expect to incorporate integration node owned servers into the same commands and interfaces in future.

Until now, users have run the mqsisetdbparms command to specify credentials. For users who are new to App Connect Enterprise the name of this command might seem confusing. The command dates from a much earlier version of ACE when databases were the main external system that the product required credentials to access. Over time the syntax of this command was then extended for other systems and protocols. Execution of mqsisetdbparms stores the credentials on the runtime system. The files which are used are obfuscated using a private algorithm, but they are not encrypted. This approach doesn’t present any problems, for users implementing heavily secured systems as other steps are available to fully protect access, such as using file-level or volume-level encryption to protect the contents of the product configuration directory. However, over time we expect users will gradually wish to adopt the new capabilities described below which provide the option of full encryption using a built-in vault. Note that there is no mandatory need to move away from mqsisetdbparms, so there is no urgent need for action for users who are not ready to embrace this new feature.

There are two new commands used in this feature area:

• mqsivault: Before you can store encrypted credentials for an independent integration server, you must configure an App Connect Enterprise vault. You create a separate vault for each integration server, and each vault has its own vault key. You can use the mqsivault command to create or destroy a vault, to change or verify a vault key, or to retrieve credentials from the vault. The vault stores the credentials (in encrypted form), and the independent integration server uses them to access secured resources.
• mqsicredentials: You can use the new mqsicredentials command to configure an independent integration server to use encrypted credentials for connecting to a secured resource. You can use the mqsicredentials command to create, update, report, and delete credentials for independent integration servers. You can use the command to create and report credentials when the integration server is running or stopped, but you must stop the integration server before you can update or delete credentials.

To get a feel for the new feature, you can try it out using the following steps:

• Create a working directory for an independent integration server:
  mqsicreateworkdir C:\ExampleWorkDir
• Create a vault which will hold the encrypted credentials:
  mqsivault --work-dir C:\ExampleWorkDir --create --vault-key myvaultkey
• Start the independent integration server (remembering to pass in the value of your vault key!):
  IntegrationServer --work-dir C:\ExampleWorkDir --vault-key myvaultkey --console-log --admin-rest-api 7600 --http-port-number 7900
• Create a credential in the vault:
  mqsicredentials --work-dir C:\ExampleWorkDir --vault-key myvaultkey --create --credential-type smtp --credential-name mysmtpcred --username ben --password mysmtppassword

In the commands above, it is the vault key which grants the command, or the Integration Server, access to the vault. These examples specify the value via the vault-key command line parameter. Alternatively you can specify a vaultrc-location parameter which avoids the user showing their secret vault-key when typing terminal commands. The rc in vaultrc stands for “run command” and can be thought of conceptually in the same way as .bashrc. Another alternative is to use an environment variable named MQSI_VAULT_KEY. Details of these options are provided in the Knowledge Center.

You should then be able to use a web browser to connect to the integration server. Note there is now a new credentials tab:

You can select a credential to see the non-secret parts displayed:

You can then refer to credentials from other areas of the product in the usual way.

Fix pack 6 continues our efforts towards making all policy types redeployable. In this fix pack policies of type User-Defined can now be redeployed, allowing updated values to dynamically take effect without needing to restart the integration server process. With ACEv11.0.0.6, the status of all the policy types is now shown below.

These (19) policies can be redeployed:

• Activity Log
• Aggregation
• Connect:Direct Server
• CICSConnection
• Collector
• CORBA
• EmailServer
• FtpServer
• IMSConnect
• JDEdwards Connection
• MQEndpoint
• PeopleSoft Connection
• Resequence
• SAP Connection
• Siebel Connection
• SMTP
• Timer
• User Defined
• Workload Management

These (10) policies cannot be redeployed (use the Delete all resources option and then deploy the updated policy):

• DotNet Application Domain
• Java Class Loader
• JDBC Providers
• JMS Providers
• MQTTPublish
• MQTTSubscribe
• Security Profiles
• TCPIP Client
• TCPIP Server
• WXS Server

IBM App Connect Enterprise v11 provides users with a WebSphere Adapter node drawer in the message flow palette of the Toolkit which contains nodes for connecting with the Enterprise Information Systems SAP, Siebel, PeopleSoft and JD Edwards. Although these functional capabilities have been available since v11 was first released in March 2018, the recent fix pack 6 release provides users with new policy types for Siebel, PeopleSoft and JD Edwards. These policies allow you to abstract various connection details away from the message flow itself, making it easier to move and re-use the same message flows across multiple environments (eg Test, QA, Production etc). The example for Siebel shown in the picture includes a Connection URL and Idle Timeout properties. Connection details can be provided to the runtime either from an adapter component or with this enhancement from a policy. For convenience, these new policy types for Siebel, PeopleSoft and JD Edwards can all be redeployed dynamically, which is an advantage over IBM Integration Bus v10 where to pick up the new values from the equivalent configurable service definitions, the integration server required a restart.

Since the last ACE fix pack was released three months ago, we have been busy creating a large number of new product tutorials. Tutorials are useful for teaching some basics to those who are new to the product, but they can also be helpful for more experienced users by providing some reusable examples for demonstrating product concepts. All the product’s tutorials (71 currently, but growing all the time!) are available on public Github within the OT4I (Open Technologies for Integration) organisation. However, the best way to access the ACE tutorials is from a machine with an internet connection and the ACE Toolkit installed. Go to the Help menu and choose the Tutorials Gallery option and the tutorial navigator will be opened:

If you don’t have the internet available on your Toolkit machine, or if you’d like to checkout the tutorials before installing the product, then you will find links to browse the instructions and download all the tutorial artifacts from this handy web page. You will also find a set of instructions for manually downloading the tutorials on this page.

The Publication message flow node has been enhanced in this fix pack to to utilise an MQ Client connection and enable messages to be published to a queue on a remote MQ queue manager. The MQ connection properties which are configured on the node itself can also be overridden at run time using an MQEndpoint policy. The screenshot below shows the new MQ Connection tab of the node’s properties:

Alternatively, flow developers can assign the name of an MQEndpoint Policy (qualified by a Policy Project) on the publication node’s Policy tab:

When the message flow is deployed as shown in the picture above, the connection information defined in the policy can be used to provide or override the MQ connection settings.

Fix pack 6 introduces a new option on the mqsireportflowmonitoring command for extracting a monitoring profile which reflects the monitoring settings on a currently deployed message flow. Monitoring profiles are XML files which list the event sources in the message flow, and define the properties of each event. A monitoring profile can be dynamically applied after a message flow has been deployed to override its current monitoring settings. Consider a very simple message flow example, which has a monitoring event defined on its HTTP Input node as shown:

Once deployed, the new option on the mqsireportflowmonitoring command can be used as shown in the screenshot of the ACE command console below:

The extracted monitoring profile in this example is shown below:

ACE users might use this kind of approach as a starting point to then further edit the profile to include configuration for the precise style of monitoring required.

The new option which we’ve been exploring with the mqsireportflowmonitoring command, is underpinned by a new method in the product’s administrative REST API:

• HTTP POST to /apiv2/servers/{server}/applications/{application}/messageflows/{messageflow}/extract-monitoring-profile

A user-defined property (or UDP for short) is a property that is defined on a message flow in the Toolkit. This property can be referred to programnatically within the logic of the flow to drive its behaviour. There are three options for accessing the value of a UDP at runtime: Compute node ESQL, java in a JavaCompute node, or a graphical data map. From Fix pack 6 of App Connect Enterprise, you can now change the behaviour of your flows at runtime by altering the value of a message flow UDP using a method provided by the administrative REST API. Consider a simple example message flow which has a UDP named MyUserDefinedProperty1. The two screenshots below demonstrate how the UDP has been defined with a default value of “Default”, and how the current assigned value before deploying the flow is the value Ben:

This example message flow uses a simple ESQL instruction to assign the current value of the UDP to an output JSON message which is sent as an HTTP reply from the message flow:

Once this message flow is deployed, you can query the current value of the UDP, and also apply a new value for the UDP, using a simple HTTP client program such as Curl:

For more information about the administrative REST API methods, you can explore the Open API specification document which is served on the URL /apidocs from all integration nodes and standalone integration servers. Two methods are provided:

• HTTP POST to /apiv2/servers/{server}/applications/{application}/messageflows/{messageflow}/apply-global-udp-override?name=NAME&value=VALUE&type=TYPE
• HTTP POST to /apiv2/servers/{server}/applications/{application}/messageflows/{messageflow}/remove-global-udp-override?name=NAME