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.
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)