A Design Pattern and Step-by-Step Implementation Guide for Salesforce Cloud Integration through IBM Integration Bus (v9).
Showing posts with label EAI. Show all posts
Showing posts with label EAI. Show all posts
Monday, November 21, 2016
Tuesday, November 1, 2016
10 Key features in IIB V 10
IBM Integration Bus V10 was released quite some time from now. IIB V10 is the second release of Integration Bus family after Websphere message broker is re branded as IBM integration Bus. The new release is having some popular new features. Popular in the sense, these features were demanded over communities or RFEs.
I would like to write the 10 new features which I like the most from IIB V10 in this post. These are my personal choice and I would not say these are the only key features in IIB V10.
1. Removal of the WebSphere MQ prerequisite
This is one of the strategical move to decouple two IBM products. Like few other vendor ESB products, messaging engine is not tightly coupled with the ESB. This can be a nice feature where an organization is not using IBM MQ for their MOM, but heavily uses Webservices or other protocols.
WebSphere MQ is no longer a prerequisite for using IBM Integration Bus on distributed platforms, which means that you can develop and deploy applications independently of WebSphere MQ. You can also run and administer integration nodes without requiring the WebSphere MQ Explorer.When you purchase a license for IBM Integration Bus, your license entitles you to install and use WebSphere MQ with IBM Integration Bus, enabling you to use the IBM Integration Bus capabilities that require MQ functionality, such as the MQ nodes and event driven processing capabilities such as message aggregation and sequencing.
For more information about using WebSphere MQ with IBM Integration Bus, see Enhanced flexibility in interactions with WebSphere MQ
But definitly there is a trade off when there is No IBM MQ with IIB. Few are listed below:
The following IBM Integration Bus features require WebSphere MQ Server to be installed on the same machine as the integration node, and they are available for use only if you specify a queue manager on the integration node:Record and replay
Global transactionality
Event-driven processing nodes (aggregate, collector, sequence, resequence, and timeout nodes)
FTEInput and FTEOutput nodes
CDInput and CDOutput nodes
SCA nodes (with MQ bindings)
Integration nodes with HTTP listeners
HTTP proxy servlet
High availability configurations
2. Shared libraries
Applications and Libraries were one of the key feature in WMB V8 release. Though Libraries are designed to isolate common reusable objects, but when it is using by an Application, application always take its own local copy. So this was not a common object when used by an Application. In IIB V10, we have shared Library to overcome this behavior. Libraries are now what it is originally designed for.
As Per InfoCenter:
Shared libraries are introduced to share resources between multiple applications. Libraries in previous versions of IBM Integration Bus are static libraries.
If you use a static library to contain resources, each application that references that static library is deployed with its own private copy of that library. If a static library is updated, each application that references it must be redeployed with the updated static library. A shared library is deployed directly to an integration server. Any application can reference the resources in that deployed shared library. If that shared library is updated, the changes are immediately visible to all referencing applications.
3. Test your message flows by using the Flow Exerciser
This is one of the key feature in the Integration toolkit. Flow exerciser will help to trace the message flow path more easily.
To check that a message flow is processing messages as expected, you can send messages to the flow, see the path that each message took, and view the structure and content of the logical message tree at any point in a message flow.
Steps below will demonstrate this very briefly.
To start the flow exerciser, click the start recording on the flow exerciser tab:
This will deploy the flow integration bus and will give a prompt with details of capturing the message path.
Once deployed, you can send a sample message to the flow and trace the message path:
Once messages send and completed, the flow will highlight the message path on the flow:
Click on the highlighted connection to see the message structure (Headers & Payload)
Once done, you can stop the flow exerciser to stop recording the messages.
4. mqsireportdbparms command
You can return a list of parameters that are set on an integration node. In addition, you can use the mqsireportdbparms to check if security credentials are set, or identify if you are using the correct password for an integration node.
Details in InfoCenter
5. Fixed naming for DataDirect ODBC database drivers
In previous IIB/WMB versions, data direct drivers will be installed on each fix pack and you need to manually update the driver path in odbc ini file each time when you install a fix pack.
ODBC database drivers now have a fixed naming convention, which means that you do not have to update links to drivers and switch files after you update to a later version.
Details: here
6. Flexible interaction with WebSphere MQ
On distributed systems, support for WebSphere MQ has been extended, introducing greater flexibility in the interactions between IBM Integration Bus andWebSphere MQ. You can configure local or client connections to WebSphere MQ, enabling your integration nodes to get messages from or put messages to queues on any local or remote queue manager. On z/OS®, you can have MQ message flow nodes connect to different local queue managers, not just the queue manager that is specified on the integration node.
You can specify a connection from an MQ node to a specific local or remote queue manager by using connection properties on the MQ node, including the destination queue manager name, host name, port, and channel. Alternatively, you can specify a queue manager on the integration node to be used for MQ processing that is required by flows in the integration node; the queue manager that you specify is then used for all message flow nodes that do not have queue manager connections explicitly defined or policies attached. For more information about policies, see Operational policy.
You can also create message flows that contain multiple MQInput and MQOutput nodes, each of which can access different queue managers as specified in the node; this enables you to adapt your message flows to your existing WebSphere MQ topologies. For more information about local and client connections between WebSphere MQ and IBM Integration Bus, see Configuring connections to WebSphere MQ.
7. Flexible administration security
You can choose between two modes of authorization when you enable administration security on an integration node: file-based authorization (file mode) or queue-based authorization (mq mode). You can specify your chosen authorization mode by using the mqsichangeauthmode command. If you configure the integration node to use file mode, you can set file-based permissions for accessing integration nodes and resources. These permissions are set using themqsichangefileauth command. Alternatively, if you have installed WebSphere MQ and specified a queue manager on the integration node, you can control access to the integration node and its resources by setting permissions on WebSphere MQ authorization queues.
8. Using the Environment tree as input data to your transformations
In a message map, you can update, delete, or create data in the environment tree Variables folder. You can use the environment tree as input data to your transformations.
Details:here
9. Business transaction monitoring
Typically, a business transaction consists of several system-level transactions. When you monitor business transactions in IBM Integration Bus, you track and report the lifecycle of a payload message through an end-to-end enterprise transaction. To monitor business transactions, you create a business transaction monitoring definition in the web user interface.
10. Develop integration solutions by using REST APIs
You can now use REST APIs to create your integration solutions.
For more information about REST APIs, see Developing integration solutions by using REST APIs
- References:
EAI, ESB, SOA
INTRODUCTION
This paper aims to bring clarity to terms EAI, ESB, SOA and provide a clear distinction. Also
this paper would discuss architecture options available for enterprise integration and what
these options are most suitable for. Finally this paper would address the discussions we
have seen in various forums about whether EAI is going to be replaced by SOA or ESB.
SOA- Service oriented architecture is approach to have software resources in an enterprise available and discoverable on network as well defined services. Each service would achieve a predefined business objective and perform discrete units of work. The services are independent and do not depend on the context or state of the other services. They work within distributed systems architecture. Earlier SOA used COM or ORB based on CORBA specifications and recent SOA stress on web services using standard description (WSDL), discovery (UDDI) and messaging (SOAP). Service oriented architecture may or may not use web services but yes web services provide a simple way towards service oriented architecture albeit with the age old security and reliability limitations.
EAI -Enterprise application integration is a business need to make diverse applications in an enterprise including partner systems to communicate to each other to achieve a business objective in a seamless reliable fashion irrespective of platform and geographical location of these applications. It is a business need and business never dies it only evolves. I have seen people saying that EAI is a thing of past now SOA is here, it is just like saying “transportation is a thing of past now road is here”. EAI comprises of message acceptance, transformation, translation, routing, message delivery and business process management. Usually messages transportation is asynchronous but for a business need it can be synchronous as well. There are two basic architectures to achieve this, bus and hub/spoke architecture. Both of these can be used to develop services and then it also becomes service orientated architecture.
ESB- Enterprise service bus is an infrastructure to facilitate SOA. It gives API which can be used to develop services and makes services interact with each other reliably. Technically ESB is a messaging backbone which does protocol conversion, message format transformation, routing, accept and deliver messages from various services and application which are linked to ESB. Current EAI landscape is seeing many vendors who offer enterprise service bus and claim it to be a brand new concept. This brings a question on what exactly is the difference between ESB and the bus based implementations which have been there in market for quite a long time now. Actually there is not much difference between ESB and proprietary buses except for a few subtle ones. Main difference between ESB and proprietary bus implementation is of cost which is significantly low for ESB. Reason for this cost difference is two fold, first proprietary bus offers lot of built in functionalities as a suit of product which need to be developed for ESB implementations based on business requirement, second most proprietary buses use some proprietary formats to enhance the performance and that increases the cost. ESB on the other hand is usually standard based, so it is a tradeoff between performance and cost between proprietary bus and ESB. Main advantage of ESB is that it costs much less then hub/spoke or bus based product suits and that it is standard based.
Please visit the link for more information
SOA- Service oriented architecture is approach to have software resources in an enterprise available and discoverable on network as well defined services. Each service would achieve a predefined business objective and perform discrete units of work. The services are independent and do not depend on the context or state of the other services. They work within distributed systems architecture. Earlier SOA used COM or ORB based on CORBA specifications and recent SOA stress on web services using standard description (WSDL), discovery (UDDI) and messaging (SOAP). Service oriented architecture may or may not use web services but yes web services provide a simple way towards service oriented architecture albeit with the age old security and reliability limitations.
EAI -Enterprise application integration is a business need to make diverse applications in an enterprise including partner systems to communicate to each other to achieve a business objective in a seamless reliable fashion irrespective of platform and geographical location of these applications. It is a business need and business never dies it only evolves. I have seen people saying that EAI is a thing of past now SOA is here, it is just like saying “transportation is a thing of past now road is here”. EAI comprises of message acceptance, transformation, translation, routing, message delivery and business process management. Usually messages transportation is asynchronous but for a business need it can be synchronous as well. There are two basic architectures to achieve this, bus and hub/spoke architecture. Both of these can be used to develop services and then it also becomes service orientated architecture.
ESB- Enterprise service bus is an infrastructure to facilitate SOA. It gives API which can be used to develop services and makes services interact with each other reliably. Technically ESB is a messaging backbone which does protocol conversion, message format transformation, routing, accept and deliver messages from various services and application which are linked to ESB. Current EAI landscape is seeing many vendors who offer enterprise service bus and claim it to be a brand new concept. This brings a question on what exactly is the difference between ESB and the bus based implementations which have been there in market for quite a long time now. Actually there is not much difference between ESB and proprietary buses except for a few subtle ones. Main difference between ESB and proprietary bus implementation is of cost which is significantly low for ESB. Reason for this cost difference is two fold, first proprietary bus offers lot of built in functionalities as a suit of product which need to be developed for ESB implementations based on business requirement, second most proprietary buses use some proprietary formats to enhance the performance and that increases the cost. ESB on the other hand is usually standard based, so it is a tradeoff between performance and cost between proprietary bus and ESB. Main advantage of ESB is that it costs much less then hub/spoke or bus based product suits and that it is standard based.
Please visit the link for more information
Wednesday, October 26, 2016
Adding an SFTP client policy
How to add an SFTP client policy to a user agent.
About this task
The user agent controls the client settings for outgoing SFTP connections for requests that match the URL expression. These settings can be further overridden by query parameters in the URL that initiates the file transfer.
Without SFTP client policies, the client authentication settings are controlled by the basic authentication and public key authentication policies.
Availability: These setting are available for only appliances with the B2B feature.
Procedure
- In the search field, enter User Agent.
- From the search results, click User Agent.
- Click the name of a user agent configuration.
- Click the SFTP Client Policies tab.
- Add a policy.
- Click Add.
- In the URL Matching Expression field, enter a shell-style expression to be the matching pattern for the URL set.
- From the SSH client profile list, select an SSH client profile.
- Optional: Set the Use unique file names property to off to disable the generation of a unique file name for puts to a remote directory.
- Click Apply.
- Optional: Repeat the previous step to add another policy.
- Click Apply to save the changes to the running configuration.
- Click Save Configuration to save the changes to the persisted configuration.
Subscribe to:
Posts (Atom)