Git plugin for IIB 10.0.0.15

 https://archive.eclipse.org/egit/updates-4.1

IBM FTM - Financial transaction Manager interview questions Basics

 1. what is PT wrapper, how channels will be select in PTWrapper.

2. how select channel subflow works on what bases it will select the channel

3.in what all the tables data will insert when PT log is done

4.from where your event will trigger for the first time

5. what are the parameters u passed in event from ur action

6.what is begin mapper and endmapper how it works

7.what is ISF message what it contents

8.what is batch and transaction 

9. what is state , transtion and event

10. how ur object filter works

11.what is the use master object query

12.what all the components contains in congfig

13. what is service particient and involded parties

14.how ur RSA and IIB will connect

15.what is business concept what is the role

16.how u will loopback in FSM

17.what is classification

18.if something went wrong of the action how ur FSM will behave what will happen with particular state in FSM

19.what ur FSM and CONFIG scripts contains

WebSphere Message Broker Commands

 To view the Components (Broker, Configuration Manager & Queue Manager associated with the Broker) created:

mqsilist

To view the Execution Groups created under a particular Broker: (The 4-digit number displayed against each Execution Group is the Process ID of the Process DataFlowEngine.exe which corresponds to an Execution Group)

mqsilist BROKER_NAME

To view the Flows & Resources (Jars, Message Dictionaries, Message Maps etc) deployed onto a Broker’s Execution Group:

mqsilist BROKER_NAME -e EXECUTION_GROUP_NAME

To view the Broker’s EG Properties:

mqsireportproperties BROKER_NAME -e EXECUTION_GROUP_NAME -o ObjectName -n PropertyName

To view all the properties of a Broker’s EG (‘-r’ indicates recursive fetch, use ‘-a’ for non-recursive fetch):

mqsireportproperties BROKER_NAME -e EXECUTION_GROUP_NAME -o AllReportableEntityNames -r

To view all the Configurable properties of a Broker (‘-r’ indicates recursive fetch, use ‘-a’ for non-recursive fetch):

mqsireportproperties BROKER_NAME -c AllTypes -o AllReportableEntityNames -r

To view the Max Heap Size set to a Broker’s EG:

mqsireportproperties BROKER_NAME -e EXECUTION_GROUP_NAME -o ComIbmJVMManager -n jvmMaxHeapSize

To view the Min Heap Size set to a Broker’s EG:

mqsireportproperties BROKER_NAME -e EXECUTION_GROUP_NAME -o ComIbmJVMManager -n jvmMinHeapSize

To view the Debug Port set to a Broker’s EG:

mqsireportproperties BROKER_NAME -e EXECUTION_GROUP_NAME -o ComIbmJVMManager -n jvmDebugPort

To change the Broker’s EG Properties:

mqsichangeproperties BROKER_NAME -e EXECUTION_GROUP_NAME -o ObjectName -n PropertyName -v ValueToBeSet

To change any of the Configurable properties of a Broker (‘-r’ indicates recursive fetch, use ‘-a’ for non-recursive fetch):

mqsichangeproperties BROKER_NAME -c ConfigurablePropertyName -o ObjectName -v NewValue

To change the Max Heap Size set to a Broker’s EG: [-v parameter should be a value in Bytes]

mqsichangeproperties BROKER_NAME -e EXECUTION_GROUP_NAME -o ComIbmJVMManager -n jvmMaxHeapSize -v NewValue

To change the Min Heap Size set to a Broker’s EG: [-v parameter should be a value in Bytes]

mqsichangeproperties BROKER_NAME -e EXECUTION_GROUP_NAME -o ComIbmJVMManager -n jvmMinHeapSize -v NewValue

To change the Debug Port set to a Broker’s EG: [-v parameter should be a 4-digit value]

mqsichangeproperties BROKER_NAME -e EXECUTION_GROUP_NAME -o ComIbmJVMManager -n jvmDebugPort -v NewValue

________________________________________________________________________

Commands for taking trace: [-u indicates ‘User Trace’ and -t indicates ‘Service Trace’]

Values of -l (Trace Level) parameter:

1. normal,

2. none,

3. debug.

Values of -m (Mode) parameter:

1. safe,

2. fast.

User Trace:

To view the user trace: (Optional -f to view the trace level of a particular message flow deployed onto an EG)

mqsireporttrace BROKER_NAME -u -e EXECUTION_GROUP_NAME -f MESSAGE_FLOW_NAME

To set the user trace: (Optional -f to view the trace level of a particular message flow deployed onto an EG)

mqsichangetrace BROKER_NAME -u -e EXECUTION_GROUP_NAME -f MESSAGE_FLOW_NAME -l TRACE_LEVEL -c SIZE_OF_TRACE_IN_KB

Service Trace:

To view the service trace: (Optional -f to view the trace level of a particular message flow deployed onto an EG)

mqsireporttrace BROKER_NAME -t -e EXECUTION_GROUP_NAME -f MESSAGE_FLOW_NAME

To set the service trace: (Optional -f to view the trace level of a particular message flow deployed onto an EG)

mqsichangetrace BROKER_NAME -t -e EXECUTION_GROUP_NAME -f MESSAGE_FLOW_NAME -l TRACE_LEVEL -c SIZE_OF_TRACE

To read the trace file: (Optional -f to view the trace level of a particular message flow deployed onto an EG)

mqsireadlog BROKER_NAME -u/-t -e EXECUTION_GROUP_NAME -f MESSAGE_FLOW_NAME -o PATH_TO_FILE_WITH_NAME_AND_EXTENSION

________________________________________________________________________

To create a BAR file:

mqsicreatebar -data PATH_TO_BAR_DIRECTORY -b BAR_FILE_NAME -p PROJECT_NAME -o NAME_OF_THE_RESOURCE_TO_BE_ADDED_WITH_EXTN

[‘-cleanBuild’ parameter can be used to refresh the workspace projects and perform a clean build before adding]

Syntax: mqsicreatebar -data workspace -b barName [-version id] [-esql21] [-p projectName […]] -o filePath1 [filePath2 […]]

Command Options:

‘-data workspace’ workspace location (Mandatory)

‘-b barName’ bar file name to create or replace

‘-version id’ appends ‘_’ and id to compiled names in the archive (optional)

‘-esql21’ compile ESQL for brokers version 2.1 (optional)

‘-p projectName’ specify projects containing files to link (optional, multiple projects can be specified)

‘-o filePath1’ workspace relative path (including the project) of deployable files to add to the broker archive. Multiple deployable files can be compiled in a single mqsicreatebar command.

To cancel all outstanding deployments:

mqsideploy -n PATH_TO_CONFIGURATION_MANAGER_FILE -c

To deploy a BAR file:

mqsideploy -n PATH_TO_CONFIGURATION_MANAGER_FILE -b BROKER_NAME -e EXECUTION_GROUP_NAME -a PATH_TO_BAR_FILE_NAME

To remove a flow or resource from the Broker’s EG:

mqsideploy -n PATH_TO_CONFIGURATION_MANAGER_FILE -b BROKER_NAME -e

EXECUTION_GROUP_NAME -d FLOW_OR_RESOURCE_NAME_TO_BE_UNDEPLOYED

NOTE:

1. For all the mqsideploy commands above, a combination of -i, -p & -q parameters can be used instead of -n. -i carries the machine name, -p indicates the port on which the Queue Manager is open and -q represents the name of the Queue Manager,

2. An additional ‘-w’ parameter can be added at the end of the command to set a Timeout Value (in seconds).

________________________________________________________________________

To reload/restart a particular Execution Group:

mqsireload BROKER_NAME -e EXECUTION_GROUP_NAME

To reload/restart all the Execution Groups of the Broker: [This command does not restart the Broker]

mqsireload BROKER_NAME

________________________________________________________________________

To stop a Broker: [Optional ‘-i’ parameter before BROKER_NAME immediately stops the Broker, else, the Broker is stopped in Control Mode. Optional ‘-q’ parameter after BROKER_NAME stops the Broker’s Queue Manager along with the Broker]

[CONFIGURATION_MANAGER_NAME, USER_NAME_SERVER or DATABASE_INSTANCE_MANAGER can be used in place of BROKER_NAME to stop the respective Component]

mqsistop BROKER_NAME

To stop a Broker’s EG:

mqsistop BROKER_NAME -e EXECUTION_GROUP_NAME

To stop a Message Flow running on a Broker’s EG:

mqsistopmsgflow BROKER_NAME -e EXECUTION_GROUP_NAME -m MESSAGE_FLOW_NAME

________________________________________________________________________

To start a Broker:

[CONFIGURATION_MANAGER_NAME, USER_NAME_SERVER or DATABASE_INSTANCE_MANAGER can be used in place of BROKER_NAME to stop the respective Component]

mqsistart BROKER_NAME

To start a Broker’s EG:

mqsistart BROKER_NAME -e EXECUTION_GROUP_NAME

To start a Message Flow running on a Broker’s EG:

mqsistartmsgflow BROKER_NAME -e EXECUTION_GROUP_NAME -m MESSAGE_FLOW_NAME

________________________________________________________________________

To set the DSN Name to a Broker which will be used by the flows deployed onto its’ EGs:

mqsisetdbparms BROKER_NAME -n DSN_NAME -u USER_ID -p PASSWORD

To reset the DSN Name to a Broker which will be used by the flows deployed onto its’ EGs:

mqsisetdbparms BROKER_NAME -n DSN_NAME – -u USER_ID -p PASSWORD

To remove the DSN Name to a Broker which was used by the flows deployed onto its’ EGs:

mqsisetdbparms BROKER_NAME -n DSN_NAME -d

________________________________________________________________________

To list/display/export an ACL Entry:

mqsilistaclentry CONFIGURATION_MANAGER_NAME -n .configmgr_FILE_NAME -f FILE_TO_WHICH_THE_ACL_ENTRIES_ARE_EXPORTED

To create an ACL Entry:

mqsilistaclentry CONFIGURATION_MANAGER_NAME -n .configmgr_FILE_NAME -f FILE_FROM_WHICH_THE_ACL_ENTRIES_ARE_IMPORTED

To delete an ACL Entry:

mqsideleteaclentry CONFIGURATION_MANAGER_NAME -n .configmgr_FILE_NAME -f FILE_FROM_WHICH_THE_ACL_ENTRIES_ARE_IMPORTED

________________________________________________________________________

To create a Broker:

mqsicreatebroker BROKER_NAME -i USER_ID -a PASSWORD -q BROKER_QUEUE_MANAGER_NAME

To create a Configuration Manager:

mqsicreateconfigmgr CONFIGURATION_MANAGER_NAME -i USER_ID -a PASSWORD -q BROKER_QUEUE_MANAGER_NAME

To create a User Name Server: [Optional ‘-r’ parameter can be added to set the Refresh Interval at the end of the command with a value in seconds. Default value is 60 seconds]

mqsicreateusernameserver -i USER_ID -a PASSWORD -q BROKER_QUEUE_MANAGER_NAME

________________________________________________________________________

To delete a Broker: [Optional ‘-q’ parameter can be added to delete the associated Queue Manager along with the Broker]

[Optional ‘-w’ parameter can be added to delete all the files related to the Broker under the work path mentioned by ‘-w’s value]

mqsideletebroker BROKER_NAME

To delete a Configuration Manager: [Optional ‘-q’ parameter can be added to delete the associated Queue Manager along with the Configuration Manager]

mqsideleteconfigmgr CONFIGURATION_MANAGER_NAME

To delete a User Name Server: [Optional ‘-q’ parameter can be added to delete the associated Queue Manager along with the User Name Server]

[Optional ‘-w’ parameter can be added to delete all the files related to the User Name Server under the work path mentioned by ‘-w’s value]

mqsideleteusernameserver

________________________________________________________________________

To create a Configurable Service:

mqsicreateconfigurableservice BROKER_NAME -c CONFIGURABLE_SERVICE_NAME -o ObjectName -n PropertyName -v PropertyValue

To delete a Configurable Service:

mqsideleteconfigurableservice BROKER_NAME -c CONFIGURABLE_SERVICE_NAME -o ObjectName

________________________________________________________________________

To perform the Component Verification:

mqsicvp COMPONENT_NAME

[COMPONENT_NAME can be BROKER_NAME or CONFIGURATION_MANAGER_NAME]

Stay Tune for Remaining Commands… 🙂

Share this:

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.