Message Image  

App Connect

Integration Development to Micro Services Principles on OpenShift – Part 3 

Mon August 03, 2020 09:30 AM

Introduction

Modern platforms, DevOps tooling and agile approaches have accelerated the rate at which organizations can bring new applications and business function to bare. At IBM we see no reason why integration developers cannot derive many of the benefits being enjoyed by application developers in those organizations in leveraging DevOps tools on modern, container based platforms to deliver agile integration.
For a full description of IBM’s position on Agile Integration please take a look at the following article which discusses Agile Integration and introduces the IBM Cloud Pak for Integration (ICP4i) based on RedHat OpenShift Container Platform.

Integration Modernization the Journey to Agile Integration – A view from the field

This is the third part of a three part article series. In this, Part 3 of the article along with it’s associated collateral we will explore using IBM Rational Integration Tester and Test Virtualization Server with IBM App Connect Enterprise (and MQ) products on RedHat Openshift.

The first part of the series of articles covers Build, deploy and run of IBM Middleware using RH Openshift OOTB features and can be found at:

Integration Development to Micro Services Principles on OpenShift – Part 1

The second part of this series of articles covers build, deploy and run of IBM middleware using Tekton on Rh Openshift and can be found at:

Integration Development to Micro Services Principles on OpenShift – Part 2

Delivering ACE and MQ services on RH OpenShift – Overview

Figure 1. ACE and MQ on RHOS Integration Micro Services – Environment

We will leverage a base App Connect Enterprise (ACE) v11.0.0.n image that has a fixed configuration and deliver integration microservices “from” that image. These integration microservices perform a single integration function, are immutable and individually scalable.ACE Microservice 3 offers a REST interface to a client connected IBM MQ Queue Manager. The MQ Queue Manager in the scenarios on this Part 3 of the articles will be based “off-cluster” on the same machine as the IBM Rational Integration Tester software.

This article is in an early form and I plan to update it with a greater level of detail.

The scenarios

In terms of tools and approached this article and associated collateral will explore:

  • Scenario 7. Mocking(Stubbing) and Testing ACE integration microservices with IBM (Rational) Integration Tester
  • Scenario 8. Mocking(Stubbing) and Testing ACE with MQ integration microservices with IBM (Rational) Integration Tester

Assuming the role of the integration developer we will explore using components of the IBM (Rational) Test Workbench to

    Scenario 7) Run and test ACE “Stubs” and ACE Integration Services
  • Mocking ACE Microservice 2 with an IBM Test Virtualization Server stub
  • Testing the ACE Microservice 2 stub using IBM Integration Tester locally and via a Public IP address
  • Use IBM Integration Tester to test ACE Microservice 1 (on RH Openshift) connected to ACE Microservice 2 Stub.
    Scenario 8) Run and test ACE microservices deployed on RH OpenShift that connect to MQ
  • Configure and test an MQ Queue Manager on your local IBM Integration Tester machine/laptop
  • Reconfigure ACE microservice 3 on RH Openshift to place a message on MQ for consumption by a “stub”
  • Use IBM Integration Tester to test ACE Microservice 3 (on RH Openshift) connected to MQ
  • Use IBM Test Virtualization Server MQ backend stub to Get and Put messages

The Persona – A standalone/disconnected integration developer

In exploring ACE and MQ on RedHat OpenShift we will assume the persona of the disconnected developer. A developer working in a standalone unit test environment. Developing integration logic, building into images, deploying the resultant containers to run on RH OpenShift and testing his work.

The Environment

Figure 2. Disconnected (standalone) Developer


Download and install IBM Rational Integration Tester v10.0.2.1

 

IBM Rational Integration Tester v10.0.2.1 is part of the IBM Rational Test Workbench v10.0.2.1.
Basic instructions for download and installation complete with visual screen captures are in the “2.Developer Experience for ACE MQ Testing With RIT v1.0.docx” document from page 5. This document can be found in https://github.com/DAVEXACOM/tekton-ace-example/tree/master/doc

Importing the IBM Rational Integration Tester ACE and MQ collateral

Download/clone the IBM (Rational) Integration Tester project collateral for these tutorials is available from github:

https://github.com/DAVEXACOM/tekton-ace-example

https://github.com/DAVEXACOM/tekton-ace-example/tree/master/IBMIntegrationTesterProject

 

The acemq-myproject-zipped-workspacev1.2.zip is a ZIP of the IBM Integration Tester workspace for testing and stubbing the ACE and MQ artefacts.

Unzip the IBM Integration Tester workspace acemq-myproject-zipped-workspacev1.2.zip to your local file system. For example:

c:\users\username\IBM\RIT10

  •     Open IBM Integration Tester and direct to workspace
  •     Open the IBM (Rational) Integration Tester.
  •     The first time the tool is opened you will Browse to open an existing project called myproject.
  •     Subsequently, you can simply open an existing project from the pull down.

note: This process is covered, with visual images in the “2.Developer Experience for ACE MQ Testing With RIT v1.0.docx” document from page 6

General Orientation of the IBM Rational Integration Tester v10.0.2.1 tooling

General orientation of the perspectives and panes in the tooling complete with visual screen captures to help you navigate the tooling is available in the “2.Developer Experience for ACE MQ Testing With RIT v1.0.docx” document from page 7.

Introducing the ACE Integration microservices

The Integration Micro Service 1 exposes a RESTFul (API) interface. This service will call Integration Micro Service 2 via it’s RestFul(API) interface.

    Integration Micro Service 1

    RESTInput(HTTP) -> Mapping Node -> RESTRequest (call Integration Microservice 2) -> RESTReply(HTTP)


Figure 3. Message Flow for ACE MS1

Figure 4. REST Interface to ACE MS1

Integration Micro Service 2

RESTInput(HTTP) -> Mapping Node Payload+"Hello from Integration Microservice 2" -> RESTReply(HTTP)

Integration Micro Service 2 simply returns a “Hello World” echo style message. Integration Micro Service 2 can be called directly.


Figure 5. REST Interface to ACE MS2

Figure 6. Mapping for ACE MS2


Figure 7. Message Flow for ACE MS2

Integration Micro Service 3

RESTInput(HTTP) -> Mapping Node -> Manage Transport Headers -> MQPut -> RESTReply(HTTP)


Figure 8. RESTful Interface for ACE Microservice 3


Figure 9. Message Flow for ACE Microservice 3

There is more detail on how the ACE integration microservices and the ACE Liveliness probe the Supporting Materials and documentation on GitHub from an earlier article written from deployment of ACE on IBM Cloud Private: https://github.com/DAVEXACOM/ACEonICPIntSupportingMaterial.

 

The ACE Toolkit Source projects for all the ACE services can be found at: https://github.com/DAVEXACOM/tekton-ace-example/tree/master/ACEMicroservicesSrcProject.



Step by Step Guide for Scenarios 7 and 8

Scenario 7. Mocking(Stubbing) and Testing ACE integration microservices with IBM (Rational) Integration Tester

note: The following instructions complete with visual screen captures of all the steps is available in document form at:

  • Git Repo: https://github.com/DAVEXACOM/tekton-ace-example/doc
  • Document: 2.Developer Experience for ACE MQ Testing With RIT v1.0.docx from page 18

Collateral – Published Repositories, registries and collateral to clone or copy

Run and test ACE “Stubs” and ACE Integration Services

Mocking ACE Microservice 2 with an IBM Test Virtualization Server stub


We will first use a local rest client to test an ACE Micro Service 2 Stub on IBM (Rational) Integration Tester

Running the ACE Micro Service 2 stub

In IBM Rational Integration Tester, stubs will only stay active for 5 minutes. So you will need to restart the stubs if the 5 minutes expires.

Note: In the full IBM Rational Test Virtualization Server, stubs can be configured to stay active indefinitely if required.

  • Select the Test Factory OR Test Lab tabs
  • Expand the Logical file hierarchy
  • Ace ms2 stub->microservice2->v1->message->add->stubs->add
  • Double click on “add” then hit the circular green “Play” button to start the stub running

In the Task Monitor pane you will see the stub task running and in the console pane at the bottom of the screen you can see the stdout and stderr from the stub as it executes.

 

Test ACE Micro Service 2 stub with a local REST client

We’ll use a REST client to test the ACE microservice 2 stub directly the first time.

POST to the following URL:
http://localhost:8080/microservice2/v1/message

with data:
{“Messages”:[“Hello From Test Client 1111”]}

You should get the following response returned

{
“Messages”: [
“Hello From Test Client 1111”,
“Hello From Test Client 2111 after change”
] }

 

This second example shows that ACE Microservice 2 is designed to build up an array of messages.

POST to the following URL:
http://localhost:8080/microservice2/v1/message

with data:
{“Messages”:[“Hello From Test Client 1111”],[“Hello From Test Client after change”]}}

You should get the following response returned
{
“Messages”: [
“Hello From Test Client 1111”,
“Hello From Test Client after change”
“Hello From Test Client after change after change”
] }

 

 

Check the results against pre-configured data:

  • Switch back to the IBM Rational Integration Tester (IRIT) and review the Test Lab->console output for your tests
  • Select the Task for the test in the Task monitor
  • Double click on the send reply line in the console – “Instance : Send Reply:’Text’ (2) – send message”
  • This brings up a comparison screen where you can compare the actual results with the expect results.

Testing the ACE Microservice 2 stub using IBM Integration Tester locally and via a Public IP address

The ACE microservice 2 stub will be running on your machine/laptop but will be called by ACE microservice 1 which is running on RH Openshift (in this example running on the IBM Public Cloud). Therefore, the ACE microservice 2 stub will need to be exposed with a public IP address.

The IBM Cloud Secure Gateway Service can be used to enable a public IP to a local machine/laptop

IBM Secure Gateway Service – Server side

Provision a free IBM Secure Gateway Service on the IBM Cloud

Follow the guide (part of the service) to:

    • Create the server side gateway
    • Download the client side component
    • Configure a server side destination

During this process:

  • Copy the gateway ID and token for use in the client side set up
  • Open the destination and copy the public IP address and port number

In our example:

cap-au-sg-prd-01.securegateway.appdomain.cloud:15299


IBM Secure Gateway Client Side

On the client side, once the client is downloaded and installed you will need the IP address that your machine is using at the time of set up (note this can change)
Use the ipconfig or similar command to find your IP address for a connected adapter.
It could be a wifi adapter with a 192. address, Bluetooth connection to mobile using a 172. address or an IBM 9. It will depend on how you are connected at the time. you need the address plus the port that IBM Rational Integration Tester has exposed for HTTP connections.

In my example the queue manager is listening on 1515 (used in a later tutorial) and my IBM Rational Integration Tester (IRIT) stub for ACE Micro Sevice 2 is listening on 8080

Returning to the Server side briefly, update the destination with the IPaddress and port number for your laptop/machine.

Back on the client side open the browser based Secure Gateway client configuration. Using the URL:

http://localhost:9003/dashboard

Add a connection using the “big +” sign:

  • Give it a name DAT480ACEst8080 for example
  • Use the copied gateway Id and token captured earlier from the server side
  • Click connect

Next set up the ACLs for the inbound connection using the URL:

 http://localhost:9003/acl

 

Type IP config on your machine/laptop to find the IP address of the currently connected adapter.

Configure the ACLs for “allow access” in the console for any IPAddress/port number combinations your laptop/machine might be known by.

 

Windows firewalls

If running on Windows you may need to configure an Inbound Rule to allow traffic via certain ports.

Test calling the RTVS ACE MS2 stub via public IP

In IBM (Rational) Integration Tester we will need to restart the ACE MS2 stub:

  • Select the Test Factory OR Test Lab tabs
  • Expand the Logical file hierarchy
  • Ace ms2 stub->microservice2->v1->message->add->stubs->add
  • Double click on “add” then hit the circular green “Play” button to start the ACE MS 2 stub running

In the Task Monitor pane select the Task run for the stub. It will have a status of ready.

You will also see the stub output in the console pane.

The IBM Secure Gateway will be offering a public IP address to connect to your laptop/machine. In my example it is:

cap-au-sg-prd-01.securegateway.appdomain.cloud:15299

Build out the URL to call an ACE MS2 by adding the base URL to the IPAddress port number:

 cap-au-sg-prd-01.securegateway.appdomain.cloud:15299/microservice2/v1/message

  

Use a REST Client to

POST to URL:

http://cap-au-sg-prd-01.securegateway.appdomain.cloud:15299/microservice2/v1/message

with data:

{“Messages”:[“Hello From Test Client 1111”],[“Hello From Test Client 2222”]}

 

The REST client should receive the response:

{

“Messages”: [

“Hello From Test Client 1111”,

“Hello From Test Client 2222 after change”,

“Hello From Test Client 2222 after change by service 2”

] }

 

Return to IBM (Rational) Integration Tester and review the console.

You should see a successful execution of the stub.

Use IBM Integration Tester to test ACE Microservice 1 (on RH Openshift) connected to ACE Microservice 2 Stub

For this test, ACE Micro Service 1 running on RH Openshift will have its RestRequest node configured with the URL it needs call the ACE Micro Service 2 stub running on IBM (Rational) Integration Tester via the public IP address offered by the IBM Secure Gateway service.

In this example that URL is: 

http://cap-au-sg-prd-01.securegateway.appdomain.cloud:15299/microservice2/v1

  

Switch to or open the IBM App Connect Enterprise Toolkit

 

Rather than changing the “source code” in the add.subflow subflow. Use the BAR override parameters on the BAR file itself to update the URL that ACE MS1 will use to call ACE MS2 to direct it to the stub on IBM (Rational) Integration Tester.

 

Next, the image on RH OpenShift will need to be replace with a new version containing the updated BAR.

    • The document “1.Developer Experience for ACE MQ with RHOS Tools and Tekton v1.1”
    • Section: Build and Run ACE Microservice 1 from SoE on RH OpenShift
    • Page: 49

Describes the following steps to rebuild,deploy and run the updated ACE MS1, if you have not already set up ACE MS1.
The steps are:

    • Save the BAR file
    • Push it to the GIT repos
    • Webhook fires and RHOS will build and deploy a new container with the updated BAR file

Switch to the RedHat Openshift Console

On RH Openshift check the logs on the triggered build/rebuild to ensure the build was successful

 RH OpenShift console->Builds->builds->ibm-ace-mqcsoe-ms1-build-n

Check the logs on the ACE MS1 pod to ensure the latest version is running

RH OpenShift console->Workloads->pods->ibm-ace-mqcsoe-ms1-build-n-xnxnxn->logs

 

ACE MS1 on RH OpenShift is now pointing (via the secure gateway) to the stub of ACE MS2 on IBM Rational Integration Tester.

Get the ACE MS1 route details from RH OpenShift console

 

RH OpenShift Console->Networking->routes->ibm-ace-mqc-soe-m1-build

Or use the openshift command line client

oc get routes

To retrieve the target hostname:

 ibm-ace-mqc-soe-ms1-build-da-build-project.apps.cloudpak.ocp4.cloudnativekube.com

 

Add the ACE MS 1 base URL to the hostname and then using a REST Client to ensure you have connectivity to ACE MS 1 and the ACE MS2 stub it is set up to call.

http://ibm-ace-mqc-soe-ms1-build-da-build-project.apps.cloudpak.ocp4.cloudnativekube.com/microservice1/v1/message

Start/Restart the IBM Rational Integration Tester ACE MS2 Stub

Note: stubs in IBM Integration Tester only run for 5 mins before needing a restart via the green “play” button

Check the console output to observe the stub is up and running


Use a REST client to call ACE MS1 (which in turn called ACE MS2 stub)

Use a local REST Client to test ACE MS2 by issuing a

POST to URL:
http://ibm-ace-mqc-soe-ms1-build-da-build-project.apps.cloudpak.ocp4.cloudnativekube.com/microservice1/v1/message

with Data:
{“Messages”:[“Hello From Test Client 111111111111111111”]}

The response should be:
{“Messages”:[“Hello From Test Client 111111111111111111”],[“Hello From microservice after change”],[“Hello From Microservice 1 after change by service 2”]}

  

In IBM Rational Integration Tester->TestLab observe results in ACE MS 2 stub console. The IBM Rational Integration Tester console should reflect a successful test


Invoking ACE MS1 on RH OpenShift from a IBM Rational Integration Tester

Next we will use IBM Rational Integration Tester to test ACE MS1 on RH Openshift, where it will call the ACE MS2 stub running back on IBM Rational Integration Tester.

Review the connectivity details for ACE MS1 in IBM Rational Integration Tester->Architecture School->Physical View.

Navigate to subnet 135.90.75 (i.e. not the local host subnet).

In the settings for the remote demo service ensure you have the ipaddress for ACE MS1 on RH Openshift.
In our example:

ibm-ace-mqc-soe-ms1-build-da-build-project.apps.cloudpak.ocp4.cloudnative.com

 

Back in Test Lab in IBM Integration Tester, ensure the the ACE MS 2 stub is still running
If not….select:

 ace ms2 stub->ace microservice2->v1->message->add->stubs->add

and start a new test run using the green “Play” button

Next we will run the ACE microservice 1 test by navigating to:

Test MQ Test ACE->ACE microservice1->Tests->testservice1

and hit the green “play” button to run the test.

Observe the results in the Test Lab-> Task Console for the ACE Micro Service 2 stub

Observe results in the console for the testservice 1 (The testing of ACE Microservice 1)


Scenario 8) Run and test ACE microservices deployed on RH OpenShift that connect to MQ

note: The following instructions complete with visual screen captures of all the steps is available in document form at:

        Git Repo: https://github.com/DAVEXACOM/tekton-ace-example/doc
        Document: 2.Developer Experience for ACE MQ Testing With RIT v1.0.docx from page 42

Collateral – Published Repositories, registries and collateral to clone or copy

Review of ACE Integration Microservice 3

The Integration Micro Service 3 exposes a RESTful (API) interface to an MQ Queue Manager

Figure 10. RESTful Interface for ACE Microservice 3
    Figure 11. Message Flow for ACE Microservice 3


    Using ACE Micro Service 3 (MS3) with a remote MQ Queue Manager

     

    Configure and test an MQ Queue Manage on your local machine (or some location accessible to the IBM Integration Tester)

    •     Create an MQ Queue Manager called MyAPPQMGR
    •     With queues FROM.BACKEND.Q and TO.BACKEND.Q
    •     Queue Manager MyAPPQMGR and Queues
    •     Add an MQ Listener that listens on port 1515
    •     Add an Server connection channel

     

    The MQ SVRCONN Channel creation for Linux based queue manager is as follows:

     

    DEFINE CHANNEL(IVT.SVRCONN) CHLTYPE(SVRCONN) REPLACE
    SET CHLAUTH(IVT.SVRCONN) TYPE(BLOCKUSER) USERLIST(nobody)
    ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(NONE) ADOPTCTX(YES)
    SET CHLAUTH(IVT.SVRCONN) TYPE (ADDRESSMAP) ADDRESS(*) MCAUSER(‘mqm’)
    REFRESH SECURITY TYPE(CONNAUTH)

     

     The MQ SVRCONN Channel creation for windows based queue manager is as follows:

     

    DEFINE CHANNEL(IVT.SVRCONN) CHLTYPE(SVRCONN) REPLACE
    SET CHLAUTH(IVT.SVRCONN) TYPE(BLOCKUSER) USERLIST(nobody)
    ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(NONE) ADOPTCTX(YES)
    SET CHLAUTH(IVT.SVRCONN) TYPE (ADDRESSMAP) ADDRESS(*) MCAUSER(‘MUSR_MQADMIN’)
    REFRESH SECURITY TYPE(CONNAUTH)


    Set up IBM Secure Gateway Service for Public IP to Queue Manager MyAPPQMGR

     

    As with the ACE Microservice 1 and ACE Microservice 2 tests and stubs in the earlier section, ACE microservice 3 will require a public IP address to access an MQ Queue Manager that is set up on you machine/laptop.

    The process is identical to that described earlier. You will need to create a new gateway and destination on the IBM cloud server side (or reconfigure the existing gateway to talk to MQ on port 1515 instead of to the IBM Integration Tester HTTP listener on port 8080)

    IBM Cloud Secure Gateway – Server Side

     

    Copy the Gateway ID and the Token for use in the IBM Secure Gateway client side set up

    Copy the Cloud:Host Port number combination from the IBM Secure Gateway Service destination

    This will be used on to override the ACE MS3 BAR parameters for the MQOutput node connection details in the microservice’s message flow.

    IBM Secure Gateway Service – Client (Laptop end)

     

    Use ipconfig command to find the IP address of a connected network adapter on your machine/laptop.
    Add it to the ACLs in the secure gateway client side console via URL:

    http://localhost:9003/acl

    In my example, 192.168.0.13:1515 will be added to the “Allow Access” section

    Windows firewall

     Again, as in the previous scenario, if running on windows you may need to create or update an inbound rule to add the port 1515 to allow connection to the MQ Listener.

    Using/Matching Secure Gateway parameters on ACE MS 3 MQOutput configuration

    Depending on whether you have completed Part 1 of these materials you will need to check and potentially change the configuration of ACE MS3 running on RH OpenShift and trigger a build/rebuild. Instructions for this can be found in

     

    •     GitHub repo: https://github.com/DAVEXACOM/tekton-ace-example/tree/master/doc
    •     Document: ”1.Developer Experience for ACE MQ with RHOS Tools and Tekton v1.1”
    •     Section: ACE MS 3 – REST Service exposing off RH OpenShift cluster MQ QMGR
    •     Page: 78

      

    There are two options in the IBM App Connect Enterprise Toolkit for configuring the MQOutput node in ACE Microservice 3 to use the secure gateway connection to resolve connectivity to the MyAPPQMGR on your machine/laptop. 

    •     Option 1: MQ configuration update in the source message flow
    •     Option 2:MQ configuration update in the BAR override

     

    With the change made and the BAR file updated and saved you will need to: 

    •     Push the BAR to GitHub
    •     Webhook trigger or manual RH OpenShift Console rebuild
    •     Wait on successful build and deployment before continuing

     

    These are the same steps you performed against ACE MS 1 in the earlier scenario in this article/document when you changed ACE MS1 RESTRequest Node URL to point to the ACE MS2 stub.

    Testing MQ via IBM Public IP – using RFHUTILC (MQ client test)

    RFHUTIL is a popular MQ test tool shipped as part of supportpac MS03. RFHUTILC is the client version.

     

    To connect to the queue manager MyAPPQMGR use the public IP address from the IBM Secure Gateway (copied earlier) as part of the connection URL for the IVT.SVRCONN channel in the following format in the “Queue Manager Name” parameter of RFHUTILC:

     

    IVT.SVRCONN/TCP/cap-au-sg-prd-02.securegateway.appdomain.cloud(15558)

     

    Set the Queue name to TO.BACKEND.Q

    Open a file with some data to act as the message then hit the WriteQ button

    Check the secure gateway client side logs via URL:

    http://localhost:9003/logs

     You should see RFHUTILs connection to the MyAPPQMGR via the public IP address.

    Check the result on the target queue manager. There should be a message on the TO.BACKEND.Q queue


    Testing ACE Microservice 3 to Put to MQ via IBM Public IP – Using a REST Client

    Obtain the RH OpenShift Route for ACE MS3 

    In the RedHat openshift console navigate to the routes. 

    RH OpenShift Console->Networking->Routes->ibm-ace-mqc-soe-ms3-build 

     

    Or use the openshift command line client command: 

    oc get routes 

    URL and test data for calling ACE MS3 service 

    Add the ACE MS 3 base URL to the ipaddress of ACE MS3 retrieved from the route. 

    Using a REST Client 

    POST to URL:
    http://ibm-ace-mqc-soe-ms3-build-da-build-project.apps.cloudpak.ocp4.cloudnativekube.com/ivtrest/v1/doiIvt
    with data:
    {
    “name”:”anyname”,
    “phone”:”123545454″,
    “email”: “anyname@host.com”
    } 

    You should receive an “Echo” style response from ACE MS3 with the data UPPERCASED

    Check Test Results on MQ 

    Using MQ Explorer, runmqsc or RFHUTILC check the messages on the TO.BACKEND.Q

     

    On Queue Manager: MyAPPQMGR

    On Queue: TO.BACKEND.Q

    Data: JSON payload with the values UPPERCASED

     

    Using the MQ Stub on IBM Rational Integration Tester as a backend application

     

    Review stub parameters in IBM Rational Integration Tester

    In the IBM Rational Integration Tester navigate to:

     Architecture School->Logical View->Test MQ Test ACE->mqTo.BACKEND.Q

     

    note that the IBM (Rational) Integration Tester stub is set up to Get from TO.BACKEND.Q and Put to FROM.BACKEND.Q.

     

    Review the activities that the MQ Stub will perform when a message is received.

     Test Factory->Logical->Test MQ Test ACE->mqTO.BACKEND.Q->Stubs->MQDemo

     

    Double click on MQDemo and select Activity.

    Depending on the inbound data payload the stub will either append the message “This is from MQ stub” to the original message or just place “This is from MQ stub” on FROM.BACKEND.Q

     

    Finally review the Physical view to check the connection details that the IBM Integration Tester will use for the Stub to connect to MQ.

     Architecture School->Physical View->subnet localhost->MQ Queue Manager MyAPPQMGR@IVT.SVRCONN@localhost:1515

    MQ stub uses the IVT.SVRCONN channel definition in the MyAPPQMGR

     The IBM (Rational) Integration Tester stub will use a SVRCONN channel to connect to the MyAPPQMGR. The channel definition is as follows:

     

    DEFINE CHANNEL(IVT.SVRCONN) CHLTYPE(SVRCONN) REPLACE
    SET CHLAUTH(IVT.SVRCONN) TYPE(BLOCKUSER) USERLIST(nobody)
    ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(NONE) ADOPTCTX(YES)
    SET CHLAUTH(IVT.SVRCONN) TYPE (ADDRESSMAP) ADDRESS(*) MCAUSER(”)
    REFRESH SECURITY TYPE(CONNAUTH)

     

    Start IBM Rational Integration Tester Stub to retrieve messages placed on MQ by ACE MS3

     

    In the Test Factory expand:

     mqTo.BACKEND.Q->Stubs->MQDemo

     

    Select the MQDemo stub and hit the green “play” button to run the stub

    IBM Rational Integration Tester Stub receives message from ACE MS3

    In the Task monitor console in the Test Lab tab observe the Stub reading and writing messages successfully

    Review MyAPPQMGR queue FROM.BACKEND.Q contents

    Depending on the test you have run with RHFUTIL and the actual ACE Micro service 3 you will have a mixture of messages on the FROM.BACKEND.Q

    Type 1: (this is from MQ stub)

    Type 2:{“name”:”ANYNAME”,”phone”:”123545454″,”email”:”ANYNAME@HOST.COM”} (this is from MQ stub)



    #develop
    #Integration
    #solution
    #Openshift
    #microservices

    Statistics

    0 Favorited
    21 Views
    0 Files
    0 Shares
    0 Downloads