Dump Queue Manager configuration to new queue manager

Run the below command in existing queue manager , Replace the QM name and file directory path in below command 

dmpmqcfg -m <QM> -a -t all -o mqsc > <file>

ex: dmpmqcfg -m TESTQM -a -t all -o mqsc > C:\Users\VenkateshRathod\Desktop\ACE training\TESTQM.mqsc

Run the below command in new queue manager where you to associate with existing

runmqsc {QM} < C:\Users\VenkateshRathod\Desktop\ACE training\TESTQM.mqsc

ex : runmqsc TESTQM1 < {file}

For other methods can follow the below link for more details :

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.con.doc/q015190_.htm

https://developer.ibm.com/tutorials/mq-connect-app-queue-manager-ubuntu/#step-2-download-ibm-mq

IIB V9 and V10 Differences , REST API ,WSDL ,DFDL ,Shared library - Static library Difference Interview queations

 --IIB V9 -V10--

1. Removal of the WebSphere MQ prerequisite

2. Shared libraries

3. Web UI for the broker

4. Test your message flows by using the Flow Exerciser

5. mqsireportdbparms command

6. Using the Environment tree as input data to your transformations

7. Develop integration solutions by using REST APIs

8.Creating message flows that use the Group nodes to provide stateless aggregation scenarios

-- REST API --

1.Creating a REST API from scratch by using the IBM Integration Toolkit.(Create a REST API and define resources and operations yourself.)

- If we create REST API from scracth then we need to define, header ,Resource and definations

-Header contaions the URL and base path for the APIs

-resource contaions the method of the REST API(GET,POST,DELETE..etc)

-definations includes basically message types like element in xml message

2.Creating a REST API from an imported Swagger document

- IBM Integration Bus supports version 2.0 of the Swagger specification

-The Swagger document must be saved in either JSON format with a .json file extension, or in YAML format with a .yaml or .yml file extension.

-You must enter a value for the operationId field in the Operation Object, and the value of the operationId field must be unique across all operations that are defined in this REST API

-The base paths of all REST APIs deployed to a single integration server must be unique. You cannot deploy a REST API to an integration server if there is already another REST API deployed with the same base path.

-The "file" JSON schema type is permitted in Swagger documents but is not supported by IBM Integration Bus; you cannot import a Swagger document that includes a reference to the "file" JSON schema type.

---WSDL --

-WSDL is an XML notation for describing a web service

-A WSDL definition tells a client how to compose a web service request and describes the interface that is provided by the web service provider.

-Contains

1.<types> Defines the (XML Schema) data types used by the web service

2.<message> Defines the data elements for each operation

3.<portType> Describes the operations that can be performed and the messages involved.

4.<binding> Defines the protocol and data format for each port type

--DFDL-

-The DFDL domain can be used to parse and write a wide variety of message formats, and is intended for general text and binary message formats, including industry standards.

-Because the DFDL parser is model-driven, it can perform validation of messages against the message model that is defined in the DFDL schema file.

Delemeter

- Saperate 

- Initiator

- terminator

- Output New line

-- Shared library - Static library

Shared :

1.Shared libraries are introduced in IBM Integration Bus Version 10.0.

2.If multiple applications reference a shared library, when the applications are deployed, each application uses the artifacts directly from the deployed shared library.

3.If you update and redeploy a shared library, all applications that reference that shared library see the updates automatically.

4.Shared libraries can be deployed directly to the integration server, or they can be deployed in the same BAR file as the applications that reference them.

5. we can view the shared libraries in referenced libraries  in toolkit

Static :

1.The libraries that were introduced in WebSphere® Message Broker Version 8.0 are renamed as static libraries.

2.If multiple applications reference a static library, when the applications are deployed, each application has its own private copy of the library and the resources that are contained in it

3.If you update a static library, you must repackage and redeploy each application that references that library, unless applications need to use different versions of that library.

4.Static libraries are packaged and deployed in the same BAR file as the applications that reference them.

5.we can view the Static libraries in included libraries project in toolkit

Reverse String in ESQL

 <Roots>

 <Names>

  <Name>Venkat</Name>

 </Names>

</Roots>

CREATE COMPUTE MODULE POC_MF_Compute

CREATE FUNCTION Main() RETURNS BOOLEAN

BEGIN

  

  DECLARE Names INTEGER 1;

  DECLARE  rInputMessage REFERENCE TO InputRoot.XMLNSC.Roots.Names;

  DECLARE stren INTEGER LENGTH(rInputMessage.Name);

  SET stren = stren + 1;

  DECLARE strlenmul INTEGER ;

  Set strlenmul = stren;

  WHILE  Names < strlenmul DO

   

   SET Environment.Variables.Names[Names] =  SUBSTRING(rInputMessage.Name from stren - 1);

   Set rInputMessage.Name = SUBSTRING(rInputMessage.Name BEFORE  Environment.Variables.Names[Names]);

   Set stren = stren - 1;

   SET Names = Names +1;

  END WHILE;

  

  DECLARE rOutputroot REFERENCE TO Environment.Variables.Names[1];

  WHILE LASTMOVE(rOutputroot) DO

  SET Environment.Varibale.output = COALESCE(Environment.Varibale.output,'')||rOutputroot;

  MOVE rOutputroot NEXTSIBLING REPEAT TYPE NAME;

  END WHILE;

  

  SET OutputRoot.XMLNSC.Message.ReverseString = Environment.Varibale.output;

RETURN TRUE;

END;

END MODULE;

Validating JSON Message in IIB

Overview

This blog helps to understand JSON parser in IIB and how to validate the incoming JSON message.

What is JSON?

JavaScript Object Notation is a lightweight plain text format used for data interchange. It’s a collection of Name-Value pair.

How IIB parses the JSON message?

In IIB JSON message realized as Object (Name-Value pair) and Array. IIB provides the feature called JSON domain. JSON parser and serializer process the messages below Data under JSON domain.

JSON parser converts the incoming bit stream into logical tree structure. It just validates the syntax of the incoming JSON message but it won’t validate the content/value of incoming message against any schema (Swagger.json). Because JSON modelling is not supported by IIB. Serializer converts the logical tree structure into bit stream.

Below picture describes the JSON logical tree structure created by JSON parser,

If syntax of the incoming JSON message is wrong, IIB sends the json parser error response as like below:

E.g.: BIP5705E: JSON parsing errors have occurred. : F:\build\S1000_slot1\S1000_P\src\DataFlowEngine\JSON\ImbJSONParser.cpp: 257: ImbJSONParser::parseLastChild: ComIbmWSInputNode: MF_JSON_POC#FCMComposite_1_1

BIP5701E: A JSON parsing error occurred on line 6 column 1. An invalid JSON character (UTF-8: ‘0x00000022’) was found in the input bit stream.  The JSON parser was expecting to find one of the following characters or types: ‘”}”, “,”‘.  The internal error code is ‘0x00000108’. : F:\build\S1000_slot1\S1000_P\src\DataFlowEngine\JSON\ImbJSONDocHandler.cpp: 550: ImbJSONDocHandler::onInvalidCharacter: ComIbmWSInputNode: MF_JSON_POC#FCMComposite_1_1</text>

Creating REST API

This section describes how to create REST API to validate the JSON message using xsd

STEP 1: Create REST API project and specify the API base path.

STEP 2: Define the JSON schema (Swagger.json) under Model Definitions. Model definition helps to create a JSON schema to define a structure of the JSON message.

JSON Schema will be created under OtherResources folder with the default name “swagger.json”.

JSON Schema:

{“swagger” : “2.0”,

“info” : {

“title” : “JSONoverHTTP”,

“version” : “1.0.0”,

“description” : “JSON meesage custom validation”

},

“paths” : {

“/customValidation/xsd” : {

“post” : {

“operationId” : “postXsd”,

“responses” : {

“200” : {

“description” : “The operation was successful.”

}},

“consumes” : [ “application/json” ],

“produces” : [ “application/json” ],

“description” : “Insert a xsd”,

“parameters” : [ {

“name” : “body”,

“in” : “body”,

“schema” : {

“$ref” : “#/definitions/PersonDetail”

},

“description” : “The request body for the operation”,

“required” : true

} ]

}

}

},

“basePath” : “/json_overhttp/v1”,

“definitions” : {

“PersonDetail” : {

“type” : “object”,

“properties” : {

“name” : {

“type” : “string”

},

“age” : {

“type”: “number”

},

“address” : {

“type” : “object”,

“properties” : {

“street” : {

“type” : “string”

},

“city” : {

“type” : “string”

},

“phoneNumber” : {

“type” : “number”,

“format” : “length=10”

}

}

},

“ValidationFlag” : {

“type” : “string”

}

},

“required” : [ “name” ]

}

}

}

STEP 3: Create a new resource.

STEP 4: Define the resource path and select the operation as post

STEP 5: click the subflow icon to implement conversion of JSON to XML and validation.

REST API Message flow will be created after doing above mentioned step .postXsd is a sub flow where the actual implementations are done. 

STEP 6: Create an XSD as per the Swagger document under a shared library and name it as PersonDeatailSchema.xsd.

STEP 7: Refer the Library to REST API.

Right click the REST API Select à Manage Library references à choose the shared library in which you have created the PersonDeatailSchema.xsd schema.

STEP 8: Add mapping node in to subflow (postXsd) to convert JSON message to xml message.

STEP 9: select Swagger.JSON as input and PersonDeatailSchema.xsd as output format. This will convert the incoming JSON message to an XML.

STEP 10: After mapping node add a validator node. configure properties Domain as XMLNSC and Validation as content and value.

Note: If the XSD is created under library no need to refer explicitly in message model. At run time broker will take the right schema to validate the incoming message.

below is the postXsd Subflow,

Testing the Message Flow

In the below test util got error response back from the REST API as “The value “1234567B91” is not a valid value for the “phonetype” datatype”.

Phone number defined as data type: number as per the JSON schema and equally phone number defined as integer in the xsd schema definition.

After converting message from JSON to XML validator node validates the incoming message against the Schema definition. As PhoneNumber field has the string value as “1234567B91” in the incoming message so validator node throws the error

Conclusion

IIB doesn’t support JSON message model but it allows you to access and manipulate the JSON message. So, validation can be achieved by creating customized code.

Sample POC on SAP Nodes

Will be post shortly

webservice URL which returns 200 HTTP response code - PETSTORE

Note : If using IIB for POC's and SSL is not configured to your local broker, it may throw SSL error, Please change the url from https to http it starts working.

1. Add a pet in petstore

HTTP method : POST

URL : https://petstore.swagger.io/v2/pet

Request :

{
  "id": 91643488483,
  "category": {
    "id": 0,
    "name": "string"
  },
  "name": "dog",
  "photoUrls": [
    "string"
  ],
  "tags": [
    {
      "id": 0,
      "name": "string"
    }
  ],
  "status": "available"
}

2. Update existing pet details

HTTP method : POST

URL : https://petstore.swagger.io/v2/pet

Request Message :

{
  "id": 91643488483,
  "category": {
    "id": 0,
    "name": "string"
  },
  "name": "sonu beta",
  "photoUrls": [
    "string"
  ],
  "tags": [
    {
      "id": 0,
      "name": "string"
    }
  ],
  "status": "available"
}

3. Find a pet by its status (available,pending,sold)

HTTP method : GET

URL : https://petstore.swagger.io/v2/pet/findByStatus?status=available


4. Find a pet by its ID

HTTP method : GET

URL : https://petstore.swagger.io/v2/pet/91643488482

5. Oder pet through store 

HTTP method : POST

URL : https://petstore.swagger.io/v2/store/order

Request message
{
  "id": 91643488482,
  "petId": 0,
  "quantity": 1,
  "shipDate": "2020-04-09T07:50:20.280Z",
  "status": "placed",
  "complete": true

}

Esql vs Java

ESQL vs Java in IIB/ACE

This blog compares two languages that are used in IIB to write transformation logic. 


Many a times there arrives a situation where one thinks which one is better to use, ESQL or Java. A java developer always gives preference to writing in Java where as a person who knows IIB prefers ESQL. 

Here I am going to compare ESQL with Java and explain some of the things based on my personal experience so that one would be able to decide which one can be used.

In reality, there is no hard and fast rule that ESQL is preferred than Java or vice versa. It all depends on the comfort level of the developer and requirements.

If you ask me, I know both Java and ESQL and having worked on both of them, I would always prefer ESQL over Java in most of the cases and go with Java only if one needs to write complex logic in ESQL which can be easily achieve in Java.


Below I will be talking in detail with respect to the following parameters. This is purely based on my learning and experience and there can be many more parameters that are available. 


1. Performance: With respect to performance, there is no major difference between ESQL and Java. The only difference that I can think of is that there will be a context switching that happens whenever Java compute node is called as ESQL is written in C and java is JVM based. So when a messages moves from message flow to java compute node context switching happens leading to a little overhead.

2. Routing: If you ever have a requirement where you need to route to more than 2 targets or to two nodes compute node is always preferable as Java compute node has only two terminals (out and alt) whereas in compute you have 5 out terminals(out, out1, out2, out3, out4) along with propagating to label options. 

Hence if routing is needed for more than 2, use compute else you can opt for Java/ESQL.

3. Labelled loops: In some scenarios, there might be situations where one has to exit the loop if a certain condition is satisfied for which one makes use of labels in while loop or for loop.

  Labelled while loop is supported both in ESQL and Java, but Labelled for loop is supported only in Java but not ESQL. So if you want to use Labelled for loop you have to opt for Java only.

4. Data Propagation: In compute node, user has to option to propagate message, message and local environment, localenvironment, Exception, Exception & message, Exception and localenvironment, All. Depending on the requirement, user can select any one of the above option from the dropdown. 

In case of Java compute node, there is no such option available, by default all data gets propagated from its out terminal.

5. ESQL functionalities: ESQL has SELECT statement which is very powerful,which can be applied to messages and databases but no such statement exists in Java. So you can chose which one to use again depending on your requirement. Be careful while using SELECT statement for large payload data as one needs to consider performance factor as well before making a decision on this

6. Regular Expressions: There is a good support available for regular expression in Java but in esql one needs to write complex logic or algorithm to achieve this. So if you requirement has regular expressions that needs to be implemented it is better to go with Java than ESQL.

7. Sorting: There is no inbuilt sorting functionality available in ESQL and one needs to write algorithm to achieve this. In case of java, sorting can be easily achieved. Again the sorting can also be achieved for XML messages using XSLT or by interacting with DB and allowing DB to sort and send back the result. But these are rare case requirement. If you have option of selecting between ESQL and java for sorting, go for Java.

8. Exception Handling: As usual, everyone knows that in java its easy to capture exception message directly by using inbuilt functions whereas in ESQL, you need to traverse through the exception list for retrieving the exception details. I have just mentioned this point to show the difference between Java and ESQL but in my view this is not a factor for deciding if you want to for ESQL or Java.

9. Shared Variables: Shared variables can be created in ESQL but cannot be accessed in java. This is based on my experience so far where I could not find a way to retrieve shared variables in java so far. If any one has a way to retrieve it, please comment on this so that I can correct this. 


I will keep updating this blog once i figure out more differences between java and ESQL. For now the above mentioned ones is what I have.