Preparing the environment to split processing between different integration servers

When you split message flow processing between different integration servers, you must configure a data router and a connectivity agent. The integration servers can be running on different integration nodes.

Before you begin

Read the concept information in Callable message flows.

About this task

When you split processing between different integration servers, your flows communicate securely by using a Switch server and connectivity agents. The Switch server is a special kind of integration server that routes data. The connectivity agents contain the certificates that your flows require to communicate securely with the Switch server. A connectivity agent must be running in each integration server where you have deployed message flows.
The diagram shows two applications in two different integration servers. Each integration server is in a separate integration node.  The CallableFlowInvoke node in a flow in application 1 uses a Switch server to call the CallableInput node of a flow in application 2.

If your callable flows and the flows that call them are all deployed on premises, you must create and configure the Switch server on premises. You must run a command that creates some configuration files. You use one of the configuration files to create the Switch server, and the other file to configure connectivity agents for each integration server where you have deployed callable flows or flows that call them. The steps for this procedure are given in this topic.

This on-premises scenario is supported on Windows and Linux® only.

If you are splitting processing between IBM App Connect Enterprise and IBM App Connect Enterprise as a Service, the Switch server is created and managed for you in the cloud. You must download an agent configuration file from the cloud, and use it to configure the on-premises connectivity agent for each integration server. For more information about configuring connectivity agents for use with App Connect Enterprise as a Service, see Preparing the environment to split processing between IBM App Connect Enterprise and IBM App Connect Enterprise as a Service.

Procedure

To prepare the environment to split processing between integration servers on premises, complete the following steps.

  1. Start an IBM App Connect Enterprise command environment.
  2. Create the required configuration files, by running the iibcreateswitchcfg command.
    You need to run the command in a directory for which you have permission to write. Alternatively, you can specify an output directory. For example, the following command creates the configuration files and saves them in the temp directory.
    Windows platformOn Windows:
    iibcreateswitchcfg /output c:\temp
    Linux platformOn Linux:
    iibcreateswitchcfg -output /temp
    If this command is successful, you see the following responses:
    Generated self signed certificate file 'c:\temp\adminClient.p12'
    Generated switch configuration file 'c:\temp\switch.json'
    Generated agentx configuration file 'c:\temp\agentx.json'
    This command creates two JSON configuration files, and a certificate, which is reserved for future use. One file (switch.json) is used to create the Switch server. The other file (agentx.json) is used to configure the agent for each integration server where your flows are deployed.
  3. Create the Switch server, by running the iibswitch command to use the configuration file (switch.json) that you created in step 2.
    Windows platformFor example, on Windows:
    iibswitch create switch /config c:\temp\switch.json
    Linux platformOn Linux:
    iibswitch create switch -c /temp/switch.json
    If the command is successful, you see a "Successful command completion" response. The Switch server is created in a special integration node called ACESWITCH_NODE_V11.
  4. Optional: To test that the Switch server is created and running, run the following command: mqsilist ACESWITCH_NODE_V11.
    If the Switch server is running, you see the following response:
    BIP1286I: Integration server 'IIBSWITCH_SERVER' on integration node 'ACESWITCH_NODE_V11' is running.
  5. Configure a connectivity agent for each integration server where you have deployed callable flows or flows that call them.
    You can configure the agent by copying the configuration file, agentx.json (that you created in step 2), to the server's iibswitch/agentx directory.
    • For an independent integration server: work directory/config/iibswitch/agentx
    • For an integration server under an integration node: $MQSI_WORKPATH/config/Node_name/Server_name/iibswitch/agentx
    For each affected integration server, the agent should automatically establish a connection to the Switch server. For example, in the App Connect Enterprise console for an independent integration server you should see the following messages:
    The connection agent for remote callable flows has established a connection to the Switch server with URL 'wss://localhost:9011'.
    The integration server component 'agentx' has been started.
    Similarly, in the Windows Application log, you should see the following messages for an integration server (N101ISAA) under an integration node (NODEIPL01):
    ( NODEIPL01.N101ISAA ) The connection agent for remote callable flows has established a connection to the Switch server with URL ''wss://localhost:9011''.   
    
    A connection agent for remote callable flows has been configured on this integration server. The connection agent has successfully connected to the Switch server.   
    
    No response required.  
    ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––-
    ( NODEIPL01.N101ISAA ) The integration server component ''agentx'' has been started.   
    
    The specified component has been started and is available for use.   
    
    No response required.  

Results

A message flow that is deployed to one configured integration server can now communicate securely with a message flow on another configured integration server. For more information about developing these message flows, see Developing synchronously callable message flows.