Using the Covast ebMS Adapter (part 2)

As described in my previous post on the Covast ebMS Adapter (part1) there are 2 ways of leveraging the functionality of the ebMS Adapter

1) Pipelines

2) Orchestration

Using pipelines

The ebXML Messaging Service pipeline components can be configured to use a specific collaboration protocol agreement (CPA) when assembling, encrypting and signing or disassembling and authenticating the ebXML message. This configuration is performed when the pipeline is selected for usage in a BizTalk port.

This requires that pipeline properties are configured so that they match the corresponding properties of the collaboration protocol agreement (CPA). The configuration is used at runtime to process messages. When a message arrives, the properties of the message, in addition to the pipeline properties, are used to locate the correct CPA and to apply the settings during message exchange.

For instance: the CPA can dictate the requirement to return an Acknowledge message and the message destination. The CPA is also used to authenticate the point of origin for the message and the identity of the sender.

1) Configure the ebMS Receive pipeline

The receive pipeline removes the message envelope, logs transaction activity to the Communication Tracking Data table, promotes message properties and passes the BizTalk compatible XML message back to the pipeline to be published to the BizTalk messagebox. The configuration phase of the installation process deploys the receive pipeline to the chosen BizTalk application where it can then be selected for use in a receive port.

2) Configure the ebMS Send pipeline

The primary purpose of the ebMS Send Pipeline is to envelope an XML message to meet ebXML transmission standards. The send pipeline serves several additional purposes.

  • Envelopes the BizTalk XML message to meet ebMS messaging standards.
  • Handles message payload encryption and signing.
  • Creates ebMS standard acknowledgements in response to incoming messages.
  • Generates the Ping and Pong message types.
  • Generates detail into the Communication Tracking Data table.

The ebMSSend pipeline uses the CPA contract to determine how to process the message, whether to expect acknowledgements etc.

When a message is passed through a port that uses the ebMSSend pipeline this message will be picked up by the ‘PickupMessagesToSend’ orchestration. This orchestration will set the required retry flag to ensure correct processing and passes the message through to the ‘RetryOrchestration’ that will submit the message to the outbound destination

clip_image002[4]

The properties should match the CPA configuration for the message exchange that is required from the port. The Action and Party determines which configuration record is used and how the message is exchanged.

Note: the URI is overruled in the pipeline based on the CPA configuration

Note2: the ping property can be used to test connections between ebMS parties.

3) Acknowledgements

Messages that need to be acknowledged should be routed to a send port with the ebMSSendpipeline configured. The pipeline recognizes that an acknowledgment should be generated and replaces the payload of the message with the ebXML acknowledgment.

The sendpipeline will use the context properties (ReceiveCPaId,….) to determine the recipient of the acknowledgment. A filter must be added to the send port configuration for the condition “AckResponseNeeded” = “True”.

clip_image002

Comments

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