Sunday 25 November 2018

How To Show Post Title Before Blog Title in Blogger

Click on Theme.
Edit HTML.
Search for
<title><data:blog.pageTitle/></title>

Replace with:-

<b:if cond='data:blog.pageType == "item"'>
  <title><data:blog.pageName/> |<data:blog.title/></title>
<b:else/>
  <title><data:blog.pageTitle/></title>
</b:if>
<data:blog.pageName/> |<data:blog.title/> <data:blog.pageTitle/>

Sunday 18 November 2018

Helpful Links

Self Study Labs

 These can be found here.

DFDL Tutorials
There is an introduction to DFDL here.
There are some very helpful DFDL tutorials here.

Sunday 11 November 2018

Properties versus MQMD folder behavior

I had a REST API message flow where I needed to backup the JSON payload to WebSphere MQ queue. I needed to set the expiry interval on the message.

My message was sourced from an HTTPInput node. This meant that I could not directly set the expiry by simply using the following ESQL statement:-

SET OutputRoot.MQMD.Expiry = '7899100';

The above statement would not have worked since my message was sourced by an HTTPInput message, no MQMQ tree existed.

When a message flow is sourced by an MQInput node there is an MQMD to parse which makes it easy to set the Expiry value.

  1. When your message flow is sourced by an MQInput node, the MQMD takes precedence over the Properties folder in terms of value propagation between the folders.
  2. When your message flow is sourced from an input node that is not the MQInput node (such as the HTTPInput node or a user-defined input node), the MQMD header does not take precedence over Properties folder .
  3. When an MQMD folder is added in a tree that was created by the HTTP Transport, this MQMD does not have control over the Properties folder and the value propagation direction is not MQMD to Properties; it is Properties to MQMD - source IBM Integration Bus Information Center.
To set the message expiry I set both the Properties.ExpirationTime and MQMD.Expiry.

SET OutputRoot.Properties.ExpirationTime = 6048000;
SET OutputRoot.MQMD.Expiry= 6048000;






Thursday 1 November 2018

Editing configurable properties in a BAR file with MQSIAPPLYBAROVERRIDE

A bar file's configurable properties can be customized without editing and rebuilding the message flows or the resources that they use.

This can be achieved in the following ways:

  1. Editing configurable properties with the IBM Integration Toolkit.
  2. Editing configurable properties with the mqsiapplybaroverride command

In this post I will concentrate on editing the configurable properties using the mqsiapplybaroverride command.

1. Use the mqsireadbar command to determine which propertes can be configured.

mqsireadbar -b <barfile> -r

e.g. mqsireadbar -b c:\myBarFile.bar -r

The above command will display the properties on the screen.

2. Use the mqsiapplybaroverride to change the properties

Command Syntax
 mqsiapplybaroverride -b barFileName [-p overridesFile] [-m manualOverrides] [-k applicationName] [-y libraryName] [-r] [-o outputFile] [-v traceFileName] 

Command options: 
 '-b barFileName' - The name of the BAR file (in zip format) to be overridden.
 '-p overridesFile' - The file name of the plain text file that contains one of these items: the integration node properties to be overwritten, the entire new deployment descriptor, or a BAR file that contains the entire new deployment descriptor.
 '-m manualOverrides' -  A comma separated list of key=value pairs that describe the overrides to apply. On Windows systems, the list must be enclosed in quotation marks (""). If used in conjunction with -p, the overrides that are specified with the -m parameter are performed after all overrides that are specified by the -p parameter have been made.
 '-k applicationName' - The name of the application to which the overrides will be applied.
 '-y libraryName' - The name of the static library or shared library to which the overrides will be applied.
 '-r' - requests that overrides are applied recursively through applications and libraries.
 '-o outputFile' - The name of the output bar file to which the bar file changes are to be made. If this name is not specified, the input file is overwritten.
 '-v traceFileName' - Verbose internal trace is sent to the specified file.
 Note: Overrides must be supplied either in the form FLOW#NODE.PROPERTY=NEWVALUE or in the form OLDVALUE=NEWVALUE. If the latter form is used, OLDVALUE must already be an overridden value in the deployment descriptor. Specify FLOW#NODE.PROPERTY on its own to remove an override.

Create a text file, and list the properties that you want to change in the following format:
property=newValue.

mqsiapplybaroverride -b <barfile> -p <overridesFile> -k <application name>

Spefify output file parameter if you dont want the bar file to be overwritten.

mqsiapplybaroverride -b c:\temp\test.bar -p c:\temp\BarFileOverride.txt -k c:\temp\test.bar

Alternatively instead of using the command console, the bar file can be overridden by using the overrides file in the web console by clicking the Overrides button and selecting the overrides file.

N.B - the user running this command should be an administrator of the machine.

Tuesday 16 October 2018

Environment and Local Environment in IIB

Environment


The environment tree is a part of the logical message tree in which you can store information while the message passes through the message flow. The Environment folder is created at the start of a thread. It stays with the thread until the thread dies.
All data that is stored in the Environment tree is stored in memory during the whole message flow and is not freed after it is out of scope. Therefore, if you need space to store local data for node work, then use the LocalEnvironment tree and avoid high memory consumption.

The environment tree differs from the local environment tree in that a single instance of it is maintained throughout the message flow. If you include a Compute node, a Mapping node, or a JavaCompute node in your message flow, you do not have to specify whether you want the environment tree to be included in the output message. The environment tree is included automatically, and the entire contents of the input environment tree are retained in the output environment tree, subject to any modifications that you make in the node. Any changes that you make are available to subsequent nodes in the message flow, and to previous nodes, if the message flows back (for example, to a FlowOrder or TryCatch node).

LocalEnvironment


The local environment tree is a part of the logical message tree in which you can store information while the message flow processes the message.
The local environment tree is made up of the following structure:
Anything in the format of LocalEnvironment.Destination.output_or_request_node_name, for example; LocalEnvironment.Destination.Email, decides what happens when information is going into an output or request node.
Anything in the format of LocalEnvironment.WrittenDestination.output_or_request_node_name, for example; LocalEnvironment.WrittenDestination.FTE, gives you information about the processed output of an output or a request node.
Anything in the format of LocalEnvironment.input_node_name.input, for example; LocalEnvironment.Adapter.Input, contains information that has been stored by an input node.
Use the local environment tree to store variables that can be referred to and updated by message processing nodes that occur later in the message flow. You can also use the local environment tree to define destinations to which a message is sent.

Conclusion


Use the Environment for scratchpad work where you need to maintain the content beyond the scope of the current node, and use the LocalEnvironment for larger scratchpad areas that are only required during the current node, and you need to release the memory after use.
If you want to keep your own values, create it in the environment tree in a subtree called Variables.

Source: IBM® Integration Bus Version Information Center

You may also be interested in these posts: Environment Tree || Populating Destination in the local environment tree

Thursday 20 September 2018

Access and Update Local Environment in Java

Access Local Environment in Java 


MbMessage localEnv = inAssembly.getLocalEnvironment();
MbElement nameVar = localEnv.getRootElement().getFirstElementByPath("Name");
String name = nameVar.getValueAsString();



Update Local Environment in Java 


MbMessage newEnv = new MbMessage(localEnv); newEnv.getRootElement().createElementAsFirstChild(MbElement.TYPE_NAME_VALUE,"Name","James"); 
outAssembly = new MbMessageAssembly(inAssembly,newEnv,inAssembly.getExceptionList(),inAssembly.getMessage()); getOutputTerminal("out").propagate(outAssembly);

Wednesday 19 September 2018

Accessing a Configurable Service using Java

The configurable service is a readily available to keep data that an integration message flow may need at runtime.

1.Create a User Defined Configurable Service using the web console and populate it.



2. The UserDefined Configurable Cervice properties can only be accessed using a JavaCompute node.

Import com.ibm.broker.config.proxy.* in your code.
  import com.ibm.broker.config.proxy.*; 

BrokerProxy b = BrokerProxy.getLocalInstance(); 
while(!b.hasBeenPopulatedByBroker())
{
   Thread.sleep(100); 
}
ConfigurableService vendorUDCS = b.getConfigurableService("UserDefined", "MyConfigService"); 
String vendorMQDetails  = vendorUDCS.getProperties().getProperty("server");


This method below will return an instance of the BrokerProxy object for the integration node to which the message flow is deployed.
BrokerProxy b = BrokerProxy.getLocalInstance();

 To ensure that the BrokerProxy object has been populated with data from the broker
  before we access the configurable service, Add the following code:
while(!b.hasBeenPopulatedByBroker()) {
   Thread.sleep(100); 
}

The statement below will return a User Defined Configurable service called 'MyConfigService' ConfigurableService vendorUDCS = b.getConfigurableService("UserDefined", "MyConfigService");

You maybe interested in this post: Accessing a User Defined Configurable Service in Java

Thursday 23 August 2018

Create a JSON Array in IBM Integration Bus

CREATE FIELD OutputRoot.JSON.Data.to_BusinessPartnerTax IDENTITY (JSON.Array)to_BusinessPartnerTax;
SET OutputRoot.JSON.Data.to_BusinessPartnerTax.Item[1].BusinessPartner = '';
SET OutputRoot.JSON.Data.to_BusinessPartnerTax.Item[1].BPTaxType = '';
SET OutputRoot.JSON.Data.to_BusinessPartnerTax.Item[1].BPTaxNumber = '';

Wednesday 18 April 2018

Create a REST API in IBM Integration Bus from scratch

File ->New ->REST API

Enter a name for the REST API. The name that you specify is used as the name of the project in the IBM Integration Toolkit.

Wednesday 11 April 2018

Invoking an SAP ODATA GET Web Service from Postman

My example will be to Get a Business Partner using Postman.

The GET response payload default format is XML. To get the payload in JSON add query parameter format=json to the GET URL.

Set Basic Authorization (username and password) on the Authorization tab.

Add a X-CSRF-Token: Fetch key value to the header. The Fetch value allows the service to return the token.



After clicking on the Send button a response will be returned.

The payload is in JSON format.

The response contains an X-CSRF token that will be used in the POST request.


You may also be interested in this post: Create SAP Adapter In IBM Integration Bus

Tuesday 16 January 2018

Invoking a SOAP Web Service in WebSphere Integration Bus

I will be using a public webservice http://www.dneonline.com/calculator.asmx.

I will be invoking a SOAP web service using the SOAPRequest node.

Create a message flow.


Create an xsd for the input message.