In this article we demonstrate some migration scenarios by creating a simple representation of flows and applications in IBM Integration Bus(IIB) version 9 and 10 and then migrating them to
IBM App Connect Enterprise (ACE) 11.
Migrating an IIB 9/10 integration node which has configurable services defined for external resources and also has a specific user ID and password associated with one or more resources using mqsisetdbparms to an ACEV11 node
Migrating an IIB 9/10 node with multiple integration servers to ACE 11 independent integration servers by using mqsiextractcomponents
Migrating an IIB V10 integration server with apps and shared library
Migrating an IIB 9/10 node from an operating system platform not supported by ACE 11
Migrating an SAP Integration flow running on IIB 10 to ACE 11
1. Migrating an IIB 9/10 integration node which has configurable services defined for external resources and also has a specific user ID and password associated with one or more resources using mqsisetdbparms to an ACEV11 node
If you have deployed a simple flow (FileInput–>FileOutput node) to an integration server and then to an IIB broker and subsequently defined a configurable service such as FtpServer.
During migration, the configurable services from V10 get converted to policies in V11. The policy project resides in the /run subfolder in the work directory. Since we didn't specify any value for the policy_project_name, policies are created in a policy project called DefaultPolicies.
For example, if the FTPServer configurable service name is 'ftpbroker', a policy file with name ftpbroker.policyxml will get created under the run\DefaultPolicies folder in the work path as illustrated in the figure below.
2. Migrating the IIB 9/10 node with multiple integration servers to ACE 11 SIS using mqsiextractcomponents
Create an application with a few message flows in the IIB 9/10 toolkit
Create an integration node called MigrationNode
Create three integration servers : MigrationServer1, Migrationserver2 and MigrationServer3
Deploy the application to all of the three integration servers.
Take a backup of IntegrationNode using the mqsibackupbroker command:
Note: We specify the –default-application DefApp option so that if there are any message flows deployed as independent projects , then they will be moved into the default application 'DefApp' as per the ACE 11 requirement to have all resources as part of an App.
Start the SIS; for example, by using the Integrationserver command:
IntegrationServer --name MigrationServer1 --work-dir C:\temp\MigrationServer1
2018-11-14 07:00:57.155836: .2018-11-14 12:30:57.204188: Integration server 'MigrationServer1' starting initialization; version '11.0.0.2' (64-bit)
....................................2018-11-14 12:31:08.690423: About to 'Initialize' the deployed resource 'Migration' of type 'Application'.
2018-11-14 12:31:08.872079: File node 'File Output' in message flow 'FileNode' has no valid filename specified as property ''.
2018-11-14 12:31:09.047675: About to 'Start' the deployed resource 'Migration' of type 'Application'.
2018-11-14 12:31:10.852566: IBM App Connect Enterprise administration security is inactive.
2018-11-14 12:31:10.896807: Integration server has finished initialization.
2018-11-14 12:31:10.993264: The HTTP Listener has started listening on port '7600' for 'RestAdmin http' connections.
To demonstrate that the configurable services defined under the IIB 9/10 nodes also get copied along with the newly migrated SIS:
Verify the folder C:\temp\MigrationServer4\run\DefaultPolicies for the FTP configurable service policy under ACE 11 SIS
FtpServer01 configurable service is available as a new policy
Open the FtpServer01.policyxml and verify your configurations, it should match with your actual FTP Server configurations
Try to start the SIS using the IntegrationServer command and verify the flow execution
IntegrationServer --name MigrationServer4 --work-dir C:\temp\MigrationServer4.....2018-11-14 07:40:46.816920: .2018-11-14 13:10:46.863852: Integration server 'MigrationServer4' starting initialization; version '11.0.0.2' (64-bit)
3. Migrating an IIB V10 integration server with Apps and Shared Library
In IIB V10, create a shared library to contain a simple subflow. Create an application with a simple message flow that uses the subflow from the shared library.
Deploy the shared library to the IIB V10 node IIBV10
For migrating the V10 node IIBV10 take a backup of the node
Create a new ACE node ACEV11
Start the ACE node ACEV11 so that the work directory is correctly set up.
Stop the ACEV11 node
Create a blank work directory for the integration server IS1 to be migrated to ACEV11
Run the mqsiextractcomponents command for migrating the V10 integration server IS1 to ACEV11 and then start the integration node ACEV11
After starting the node, connect to the integration node from the ACE toolkit. The application and shared library resources that were migrated from the IIBV10 node appear under the integration node ACEV11
The contents can also be verified from the Web Admin UI
Test the migrated flow
4. Migrating an IIB 9/10 node from an OS platform not supported by ACE 11.
The backup from any distributed platform of IIB 9/10 is recognized by ACE 11.
Hence the same procedure listed above can be followed to migrate your IIB topology to ACE 11. In short,
Take the backup of your IIB 9/10 integration node from your current distributed platform
Move it to the target ACE 11 platform
Migrate the broker using the mqsiextractcomponents command.
5. Migrating an SAP Integration flow running on IIB V10 to ACEV11.
A) Creating an SAP Integration flow on IIB V10.
Step 1: Create an SAP outbound adapter to fetch BAPI_BANK_GETDETAILS
Configure settings for the discovery agent
Provide the JAR and .DLL files that come with SAPJCo. Attached the 64-bit jar files
Select the type of connection required, the example shown below shows the Outbound connection
Configure the SAP system connection settings
On Service Discovery, select ‘RFC’ and set a filter for BAPI bank as shown below
Select the Parameters to import the Objects
Configure the Objects
Step 2: Create a simple SAP application to fetch BAPI BANK GETDETAILS
Step 3: Configure the Integration Node with SAP JCo libraries using the mqsichangeproperties command
mqsichangeproperties IIBNODE -c EISProviders -o SAP -n jarsURL -v C:\SAP_JARS
mqsichangeproperties IIBNODE -c EISProviders -o SAP -n nativeLibs -v C:\SAP_JARS
Verify that the properties have been set up correctly:
mqsireportproperties IIBNODE -c EISProviders -o SAP -r
Step 4: Deploy the resources to the Integration Server:
Step 5: Create a configurable service for the SAP adapters connection:
SAP nodes can get SAP connection details from either the adapter component or a configurable service. By using configurable services, you can change the connection details for adapters without the need to redeploy the adapters.
To change the Hostname which is set in the adapter file, we can set it using a configurable service without redeploying.
Use the SAPConnection configurable service to change connection details for an SAP adapter.
If the integration node already exists, the mqsiextractcomponents command fails unless you specify –delete-existing-node in which case the existing integration node is deleted and a new integration node with the same name is created.
The above mqsiextractcomponents command creates a new Node and Server.
All the deployed resources will get migrated under the /run directory of the created IntegrationServer. For example, on Windows:
All the deployed resources will get migrated under the /run directory.
During migration, the configurable services from V10 get converted to policies in V11.
The policy project resides in the integration node's work directory. Since we didn't specify any value for the policy_project_name, policies are created in a policy project called
'DefaultPolicies'.
The policy file created is the same name as the name of the adapter.
The contents of the policy file are as shown below.
Step 3: Start the ACE 11 integration node
mqsistart ACENODE
We can see the application and policy files listing under the V11 node in the toolkit:
Run mqsireportproperties on the ACE node to confirm the location of the jar files migrated from v10
mqsireportproperties ACENODE -c EISProviders -o SAP -r
Step 4: Test the integration flow by sending a message to fetch the record for BAPI BANK GETDETAILS
Output message obtained:
C) Migrating an integration flow from an IIB V10 integration node to an ACEV11 Independent integration server
Step 1: Using the mqsiextractcomponents command to migrate an IIB V10 integration server to an ACE 11 independent integration server.
Open the ACEV11 command console and use the mqsiextractcomponents to create the independent Integration Server(SIS) as shown below;
If the work directory already exists, the mqsiextractcomponents command fails unless you specify –clear-work-directory in which case the configuration and resources are written to the work directory, overwriting any data that might be present in the directory.
Step 2: Start the ACE 11 integration server using the IntegrationServer command
All the deployed resources will get migrated in the /run subfolder in the work directory of the independent IntegrationServer.
During migration, the values set using mqsichangeproperties at IIB V10 get added to the server.conf.yaml file in the /overrides subfolder in the work directory of the ACE 11 integration server as shown in the figure below.
The content of the server.conf.yaml file is shown below:
During migration, the configurable services from V10 get converted to policies in V11.
The policy project resides in the /run subfolder in the work directory in the case of the integration server. Since we didn't specify any value for the policy_project_name, policies are created in a policy project called DefaultPolicies.
The name of the policy file that got created is same as the name of the adapter
The content of the policy file is shown as below.
We can see the application and the policy files listing under V11 Integration Server in the toolkit:
Note: The scenario described above shows the configuration steps for an SAP outbound scenario. The same steps apply to an SAP inbound scenario.