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

UK Connected Systems User Group – BizTalk Services questions

This Wednesday I’m attending the CSUG – The Hybrid Organisation (sold out!). During my evaluation of several Integration products (BizTalk / BizTalk Services / Neuron ESB / MuleESB) I had some concerns/questions on BizTalk Services. My goal is to get answers on the following scenario a) I receive a HTTP Post with an Xml Body payload b) This contains a signature which i need to validate c) Transform the Xml body payload to another Xml message d) Perform a HTTP Post with the new Xml message to an external HTTP url and sign the message e) Route the response back, similar to the aforementioned steps, where an error needs to be mapped to a dedicated error response Challenges I'm wondering how to cope with some of the following challenges in this scenario, and would like to know resource information available which addresses some of these challenges; Validating / Signing of messages A requirement is to validate the incoming message by inspecting an signature in the message
Read more

Setting up a build server with the BizTalk Deployment Framework

Image
This chapter describes the steps to a TFS Build Server to set up BizTalk deployment with the following functionality: • Build solution • Perform unit testing Using BizUnit • Create Deployment Packages Using BDTF • Deploy to Server Using R packages created in previous step • Create documentation BizTalkDocumenter For this the following steps are required: • Installation Components (30 min) • Configuring a build account (30 min) • Setting up the build service (30 min) • Scrum template installation (30 min) • Share for the build output directory (10 min) • Adjustments Build Template for use BTDF (30 min) • Design of build definitions (60 min) • Setting BTDF (60 min) • Use BTDF • Build execution / scheduling UPDATE (21-06-2013) - When using sharedassemblies, the following URL is a big help http://mohamedradwan.wordpress.com/2013/01/31/set-custom-assemblies-path-for-host-build-service-on-the-cloud/ - For viewing the basic instructions a video is available on the following blog http:
Read more