Using the Covast ebMS Adapter (part 1)

Getting started with the Covast ebMS adapter

The Covast ebMS Adapter for BizTalk Server 2006/2009 is a suite of components that can be used to develop and deploy BizTalk solutions, which require secure and reliable data transmission. A getting started package is included with the demo version of this adapter, using a loopback scenario to demonstrate the usage of this adapter. In this multipart series i will explain the 2 methods of using the adapter.

The Covast ebMS Adapter implements the specifications of ebXML Message Services.

To get started with the ebMS Adapter, the following steps have to be followed:

· Install the adapter

· Define the collaboration protocol agreement

· Configure the adapter using pipelines or context properties inside an orchestration

This part will explain the steps to follow for setting up the adapter….Here we go…

· Install the Covast ebMS adapter

The Covast ebMS Adapter consists of several components that aid in the development of ebMS solutions. The installation process consists of a wizard that installs the necessary components and configuration database. The ebMS Adapter installs resources to a BizTalk application that can be selected during the setup. When the installation is completed the following resources are installed:

Orchestrations

· Covast.Ebxml.Retry.PickupMessageToSend

When messages are received, the ebXml Message Service Adapter Orchestration ‘PickUpMessagesToSend’ will process this message and ensure that it is processed and submitted into the message box.

· Covast.Ebxml.Retry.RetryOrchestration

The ebMS standard defines means of reliable messaging by using Acknowledge messages. To ensure that this standard is followed there is an orchestration that picks up messages submitted by the ‘PickUpMessagesToSend’ orchestration. This orchestration tries to send the message to the outbound destination.

Pipelines

· ebMSReceivePipeline.ebMSReceivePipeline

This pipeline is used to decode ebMS messages based on the CPA defined in the steps above.

· ebMSSendPipeline.ebMSSendPipeline

This pipeline is used to encode messages to ebMS messages based on the CPA defined in the steps above.

note: a filter in the port allows to require acknowledge messages; ebMSProperties.AckResponseNeeded == true

Schemas

· ebMSProperties.CovastPropertyschema

This schema contains all the properties that can be used in the ebMS Adapter.

· Covast.Ebxml.Retry.StatusMessage

Schema that defines a status message.

· Define the collaboration protocol agreement

To be able to communicate between parties, a so called collaboration protocol agreement (CPA) must be configured. This collaboration protocol agreement defines the services and technical implementation between parties; where are the services located, is an acknowledgement required, how many retries are allowed before a message is considered to be failed. This collaboration protocol agreement can be defined in any ebMS supporting tool that is capable of exporting to xml.

To use the collaboration protocol agreement with the ebMS Adapter, the xml file should be imported using the ebMS Administration console.

Each collaboration protocol agreement defines roles, these are used to determine how to

clip_image002

Figure administration console: right click and select ‘Import CPA’ in the context menu

clip_image004

Figure select party: define for which role the CPA is imported

clip_image006

Next…..

· Configure the adapter using pipelines or context properties inside an orchestration

The message is routed and processed based on the CPA properties. The message properties are contained in the BizTalk ‘message context’. The adapter supports two methods to set the message context properties, using Pipelines and by using an Orchestration to set the context properties….i will describe this in more detail in part2 and part3.

Comments

Anonymous said…
Could you please give more information about how to define CPA?

Thanks.
5:22 PM
Post a Comment

Popular posts from this blog

Azure implementation guidelines

In My post ‘ Service Bus Management ’ I pointed out a way of implementing a DTAP strategy for managing the Service Bus environment. There’s now a great post available from Microsoft which goes into more detail about other aspects of managing the Azure subscriptions and other artefacts which is quite useful when setting up your Azure environments. Follow this link to the ‘Azure Implementation Guidelines’ HTH, Sander
Read more

Focus and innovation - recap of the last 2 years

It's been a long time since my last post. Hereby a partial explanation for that, with the note that this blog will remain active for the purpose of being a resource for historical references. My IT career started with programming, and adventures within holland, as well as overseas. When I realised programming is something you can specify, I figured that providing added value is crucial for a long term career and decided to focus on process centric roles. I started with webservice integration and eventually from that to process integration using BizTalk. The great feeling when discussing high level processes and implementing solutions within days, even highly scalable and interfacing with LOB systems is great. After several years of implementing solutions like these, I started questioning if all of this work was justified by the business case, if the solution was actually contributing, if the choices had been valid. In other words, I needed to understand the choices made. When...
Read more

BizTalk Pub/sub vs Topics based routing–discussion

My colleagues and I had a brief discussion about the subject ‘Topics’ and what it brings… Do you all agree/disagree with the following statement: topic-based pub-sub messaging doesn’t really exist in BizTalk “In my opinion; I disagree, as BizTalk offers the following 'out-of-the-box' • Message Routing (f.e build in context properties like message type, trading partner, operation etc) • Content Routing (f.e. promoted properties, message inspection in orchestrations/pipelines icw orchestration logic)” My colleague Rene Brauwers Here my 2 cents…. I agree that it exists...however the current offerings in BizTalk are tightly coupled, making the usage far from perfect. When doing content based routing on custom fields (promoted properties), you will be making the solution message-coupled; Your custom message property schema is deployed, and the message filter on these fields have a direct relationship with this property schema. Making any change to this schema will g...
Read more