none
Biztalk schema exposing as WCF service with multiple operations RRS feed

  • Question

  • Hi,

    I am working on a design pattern to expose the BizTalk schema as a WCF service and thought of taking expert’s advice. I have a single schema with 30 different nodes and each one is a different message type. For this 30 message types we need to expose WCF endpoints to customer for consuming from their application.

    When I exposed this schema as WCF service, a single receive location got created in BizTalk application and in IIS there is one .svc file. I defined 30 operations for this while exposing the endpoint with wizard.

    Currently I came up with the below 2 approaches but I did not like them as there is more redundancy

    1.        Create 30 different orchestrations and each orchestration subscribes to Message Box direct binding with message type as filter.
    2.        Create a single orchestration that binds to single receive location( this location got created by wizard..) and access the operation/message type in the expression shape. Based on this value create 30 IF conditions for each message type. For this the single orchestration receive shape should have a message type of xml document and then access the type. Is it possible?

    I don’t like the above approaches as it is very difficult to maintain and also difficult to add for any new message type.

    Does anyone has good ideas for doing this?

    Thanks


    JB

    Tuesday, January 27, 2015 4:10 AM

Answers

  • In short YES.

    TWO way receive ports bound to two-way direct bound ports in the orchestration and are auto-correlated by BizTalk. Refer https://msdn.microsoft.com/en-us/library/aa954477.aspx

    If however you wish to not use Two-way Direct bound ports then there are a number of posts/blogs that have been written on how to correlate across one-way direct bound ports. This requires the use of certain BizTalk Promoted properties such as EmpCorrToken and such. This pattern if fairly well defined and used where you wish to expose the same service over One or Two way receive ports. Refer to Johns-305 article here http://social.technet.microsoft.com/wiki/contents/articles/24389.biztalk-server-using-an-orchestration-sync-or-async.aspx

    Regards.

    Wednesday, January 28, 2015 5:11 AM
  • Don't over complicate this.

    It's important to note that the Wizard makes things appear more complicated than they are.  The Receive Location for any Published Schemas or Orchestrations are essentially identical.  The only difference is the metadata that is used for WSDL.

    So, if you are not expecting to support WSDL, the Schemas would be shared with the client app separately, then the only useful thing the Wizard does is create the IIS site.

    Your Option #1 is the normal BizTalk Pattern for this and 30 different Orchestrations, one for each Message Type, is not an unusual scenario.

    Also, keep in mind that if the Orchestration uses a typed Receive Port/Shape, then the Subscription is already taken care of and you don't have to set the Filter on your own.

    Tuesday, January 27, 2015 2:03 PM
    Moderator

All replies

  • IMHO and FWIW option ONE.

    If there are 30 distinct operations and 30 distinct messages then it should be one process per message. Each orchestration should be direct bound (two-way receive port). You can then take individual nodes and manually create the op endpoint when exposing the schemas as a service.

    Regards.

    Tuesday, January 27, 2015 4:50 AM
  • Without the knowledge of your requirement, the problem you are asking seems to be a candidate for Broker implementation. 
    Meaning, you receive any type (xml document type) of message from single service which is anyways being called by all customers. Once the message is received, it internally gets distributed across the internal business process. Or, a published message in messagebox anyways will have a type namespace#root. Each customer, as you mentioned, anyways has their business process and can process the message sent to them.

    If this answers your question please mark it as Answer and if this post is helpful, please vote as helpful. Thanks !

    Tuesday, January 27, 2015 6:38 AM
  • Hi,

    The requirement is that we have a single wcf service with 30 web operations and each operation has its own request response message types. I already thought of the above mentioned two approaches and the problem with this approach is the solution is not sustainable for future enhancements. That means it requires effort to add new operation in the future and also the no of orchestrations grows lot.

    So i am thinking to have ESB kind of design patterns with single orchestration but not sure whether it is possible or not. Can we apply inbound/outbound maps with a canonical schema to achieve this kind of scenario?

    Thanks


    JB

    Tuesday, January 27, 2015 7:12 AM
  • "Canonical Schemas" are used where multiple source messages need to be addressed by a SINGLE Operation !!!

    Every operation anyway translates to a separate process. Forget that we're dealing with BizTalk for a minute, when you're writing plain we services, you introduce new service contracts (operations) when you deal with different data contracts. To come back, in BizTalk your data contracts are your schemas. So when you have multiple schemas, each requiring different processing then you need different orchestrations.

    Let us for a minute assume you've defined a single service schema (very possible with a service header and a service details where the service data contract could differ). Now you use this schema to expose ONE service endpoint (good till now). In that service you're suggesting to ADD decisions (something like a switch statement where you'll do 'x' set of activities is the message is of 'x' type and so on... How is this sustainable? Every time you introduce an new operation, you'll have to tear down and redeploy the new orchestration which will affect all other operations. During the introduction of ONE op you may touch other parts of the orchestration (multiple branches in a parallel shape anyways make the orchestration very unwieldy from a code management/support standpoint) and introduce errors in existing ops.

    Regards. 

    Tuesday, January 27, 2015 7:41 AM
  • Don't over complicate this.

    It's important to note that the Wizard makes things appear more complicated than they are.  The Receive Location for any Published Schemas or Orchestrations are essentially identical.  The only difference is the metadata that is used for WSDL.

    So, if you are not expecting to support WSDL, the Schemas would be shared with the client app separately, then the only useful thing the Wizard does is create the IIS site.

    Your Option #1 is the normal BizTalk Pattern for this and 30 different Orchestrations, one for each Message Type, is not an unusual scenario.

    Also, keep in mind that if the Orchestration uses a typed Receive Port/Shape, then the Subscription is already taken care of and you don't have to set the Filter on your own.

    Tuesday, January 27, 2015 2:03 PM
    Moderator
  • Hi,

    We have one isolated receive location created by wizard and all the 30 different orchestrations will have two way direct bound port to MessageBox with filters on message type so that each orchestration receives specific type into workflow.

    If we implement this pattern does the direct bound port remembers the caller to sent back the response from orchestration OR do we need to set any context properties in orchestration?

    Since the orchestration is not tied to physical receive port,How the direct bound receive port remembers the subscriptions for the caller to sent back the response?


    Thanks


    JB

    Tuesday, January 27, 2015 6:31 PM
  • The main question is: those 30 inbound messages, are they processed with the same logic after input?

    If the logic is the same, I can imagine this design:

    • One schema per operation. One schema per project.
    • A canonical schema for processing.
    • 30 maps on the receive port to transform inbound schemas to canonical schema.
    • One orchestration to process canonical schema.

    In this case, if you change inbound schema set, you just redeploy the correspondent schema assembly and change the map set on the port. Map is changed without redeployment, at run-time.

     If logic is different, for each inbound schema a separate workflow is created, whatever you want to process.

    The main problem with firs case is the response messages. If it is the generic, unified response, everything is OK. 


    Leonid Ganeline [BizTalk MVP]

    Wednesday, January 28, 2015 1:24 AM
    Moderator
  • Hi,

    The logic is different for all the operations so i cannot use a canonical schema with inbound maps. But if we create 30 workflows with two way direct bound port to MessageBox with filters on message type, how does the direct bound port remembers the caller to sent back the response from orchestration OR do we need to set any context properties in orchestration?


    JB

    Wednesday, January 28, 2015 3:13 AM
  • Two-way ports automatically correlate requests and responses, so you don't have to bother to do it.

    So it could be:

    * 30 independent (port + orchestration) 

    * OR one port with 30 operations + several orchestrations (some logic could be still similar for some operations)

    You don't need the filters on ports, because Orchestration with Receive shape with schema on port operation creates a subscription for this schema under hood. It should be Later Binding port not Direct port shape!

     

    Leonid Ganeline [BizTalk MVP]

    Wednesday, January 28, 2015 3:59 AM
    Moderator
  • In short YES.

    TWO way receive ports bound to two-way direct bound ports in the orchestration and are auto-correlated by BizTalk. Refer https://msdn.microsoft.com/en-us/library/aa954477.aspx

    If however you wish to not use Two-way Direct bound ports then there are a number of posts/blogs that have been written on how to correlate across one-way direct bound ports. This requires the use of certain BizTalk Promoted properties such as EmpCorrToken and such. This pattern if fairly well defined and used where you wish to expose the same service over One or Two way receive ports. Refer to Johns-305 article here http://social.technet.microsoft.com/wiki/contents/articles/24389.biztalk-server-using-an-orchestration-sync-or-async.aspx

    Regards.

    Wednesday, January 28, 2015 5:11 AM