none
What is the LOB Adapter supposed to do exactly? RRS feed

  • Question

  • I am tasked with developing an adapter for communication between a LOB and WCF (and BizTalk R2). I think using the WCF LOB ASDK is the best way to do this, but I would be grateful if someone would clarify some things:

    As far as I have understood, the adapter is supposed to retrieve and display the metadata about available operations from the LOB. A WCF Client will be generated (with ASDK tools) to consume these operations (designated at runtime?). The BizTalk WCF Adapter will allow BizTalk to communcate with the LOB Adapter. So:

    BTS (BizTalk) -> BTS WCF Adapter -> WCF Client -> WCF LOB Adapter [implement this only?] -> LOB
    correct?

    So what I have to implement is really the WCF LOB Adapter and this adapter is supposed to translate everything between LOB and WCF, right?

    For instance there is a message from BTS to the LOB. So how does BTS know which remote operation to call? Where do I specify this? In the LOB Adapter with BTS specific code? But is the LOB Adapter not supposed to allow communication with any .NET WCF compatible system? Do I need application specific code for every application that I want my adapter to be compatible with? I think not, but I cant find any information about how the translation shuold be done.

    Or should I implement the adapter in such a way that it expects a certain format (specified by me) of the messages and every application should conform to this format if it wants to communicate with the LOB? And then implement a translation of formats and parameters for every public operation in the LOB? If there are a thousand public operations in the API I need to implement a thousand translations if I want them all to be available to WCF? But then, isnt the LOB Adapter supposed to be able to display the available operations dynamically, ie. if someone adds an operation in the LOB the LOB Adapter is supposed to support it dynamically. But if I have to implement one translation for each operation, how can it be added dynamically?

    The WCF Client specifies which operations to consume (be available for BTS for instance). How do I specify which operation to call in BTS for a specific message? In an orchestration? In a send port? How?

    I have read the documentation for WCF, WCF LOB ASDK, BTS, various blogs and white papers and done the echo adapter tutorials. Maybe the answers to these questions are so obvious that none of the texts Ive read discuss it. I feel like an idiot really.

    Im sorry for the amount of text in this post, but I really need some answers to these fundamental questions. Please explain as you would explain it to an idiot since I have little experience with WCF, WCF LOB ASDK programming.


    Fann
    Friday, February 8, 2008 9:19 AM

Answers

  • Let's try this a little at a time. The first question I would ask myself is why do I need to build one. Is there one that already exists, and what are my main requirements.

     

    As far as I have understood, the adapter is supposed to retrieve and display the metadata about available operations from the LOB. A WCF Client will be generated (with ASDK tools) to consume these operations (designated at runtime?). The BizTalk WCF Adapter will allow BizTalk to communcate with the LOB Adapter. So:

    BTS (BizTalk) -> BTS WCF Adapter -> WCF Client -> WCF LOB Adapter [implement this only?] -> LOB
    correct?

    So what I have to implement is really the WCF LOB Adapter and this adapter is supposed to translate everything between LOB and WCF, right?

    BizTalk WCF Sending Adapters dynamically build client "Proxies" to communicate with another WCF Endpoint. All you need to do is set the appropiate binding configuration on the WCF Send Adapter port, and the Adapter can do the rest.  The WCF LOB Adapter framework provides a tool to easily apply the appropiate binding configuration to a WCF BizTalk Send port, as well as a .Net Client WCF Application which communicates to a WCF LOB created adapter. So your algorithm should more be:

    BTS(BizTalk) ->BTS WCF Send Adapter (Dynamic Client proxy) ->WCF LOB Adapter (you need to implement this using API's from the LOB) -> LOB

     

    Ok...

     

    So how does BTS know which remote operation to call? Where do I specify this? I

     

    By Default WCF Actions are used to specify which remore operation to call, however this is customizable according to your solution. These WCF actions can be specified using the WCF Send Adapters' Action property either through promoted properties, or the BTS.Action mapping property inside the configuration for the BizTalk WCF Send Adapter port settings inside the BizTalk Administration Console. You can specify a single action, or multiple actions based off a BTS.Operation promoted property, and let the WCF Send port do an "WCF Action" matching according to what the BTS.Operation is set to.  This can be set inside an Orchestration, or a custom pipeline component (BizTalk Translations), maybe even with maps (BizTalk transformations).

     

    should I implement the adapter in such a way that it expects a certain format (specified by me) of the messages and every application should conform to this format if it wants to communicate with the LOB? And then implement a translation of formats and parameters for every public operation in the LOB? If there are a thousand public operations in the API I need to implement a thousand translations if I want them all to be available to WCF? But then, isnt the LOB Adapter supposed to be able to display the available operations dynamically, ie. if someone adds an operation in the LOB the LOB Adapter is supposed to support it dynamically. But if I have to implement one translation for each operation, how can it be added dynamically?

     

    How you implement your adapter depends on interoperability, SOA design, Time to value, Hosting options (Besides BizTalk). From BizTalk's perspective, translation is usually done inside of pipelines, and transformations are done inside of Maps, however depending on who will eventually "Own" the adapter, you may opt to design it for the most general and adaptable use.  Adapters have the capability of metadata harvesting. In other words, the ability to query the system, in this case the LOB Application, and display a listing of "Services" or operations that can be performed every time you want to set up the adapter for use. This metadata harvesting allows for the dynamic capability. To do this each operation should have it's own message type. In the case of the WCF LOB adapters, the goal is to use WSDL and XSD's. It's up to the client to then transform, or translate the message into the correct format for the operation.  However again this is by default, you could opt to have the message format generic and have a collection of maps inside the adapter. Again this is a design question only answered by knowing you level of maintanability, interoperability, time to value, hosting and etc.

     

    HTH

    Sunday, February 10, 2008 11:36 PM
  • Dwight's answers above are absolutely on the dot. WCF action is the recommended and is the most common way to figure out which LOB operation to invoke.

     

    Just wanted to add a couple of more things about how we implemented the SAP, Siebel and OracleDB adapters on the WCF LOB Adapter SDK. We use the WCF Actions to figure out what LOB opertion the user of the adapter intends to invoke. The adapters do expect messages to be in a specific format. That does not mean that we have written a transformation for every single LOB operation. We have written a generic transformation that takes care of one class of operations - like RFCs or BAPIs or IDoc operations.

     

    Let us know how your adapter development goes.

     

    Thanks

    Monday, February 11, 2008 4:43 AM
  • The Echo Adapter tutorial contains a quick step through:

    http://technet.microsoft.com/en-us/library/bb798125.aspx

     

    HTH

    Wednesday, February 13, 2008 7:00 AM

All replies

  • Have you downloaded the Adapter Pack?  I would download and install that.  It comes with 3 LOB Adapters (SAP, Seibel, and something else Oracle?). 

     

    Then look at the samples (BizTalk and otherwise) and read the help files in there.  This is what I did and I think hit helped me out.

     

     

     

    Friday, February 8, 2008 7:36 PM
  • Let's try this a little at a time. The first question I would ask myself is why do I need to build one. Is there one that already exists, and what are my main requirements.

     

    As far as I have understood, the adapter is supposed to retrieve and display the metadata about available operations from the LOB. A WCF Client will be generated (with ASDK tools) to consume these operations (designated at runtime?). The BizTalk WCF Adapter will allow BizTalk to communcate with the LOB Adapter. So:

    BTS (BizTalk) -> BTS WCF Adapter -> WCF Client -> WCF LOB Adapter [implement this only?] -> LOB
    correct?

    So what I have to implement is really the WCF LOB Adapter and this adapter is supposed to translate everything between LOB and WCF, right?

    BizTalk WCF Sending Adapters dynamically build client "Proxies" to communicate with another WCF Endpoint. All you need to do is set the appropiate binding configuration on the WCF Send Adapter port, and the Adapter can do the rest.  The WCF LOB Adapter framework provides a tool to easily apply the appropiate binding configuration to a WCF BizTalk Send port, as well as a .Net Client WCF Application which communicates to a WCF LOB created adapter. So your algorithm should more be:

    BTS(BizTalk) ->BTS WCF Send Adapter (Dynamic Client proxy) ->WCF LOB Adapter (you need to implement this using API's from the LOB) -> LOB

     

    Ok...

     

    So how does BTS know which remote operation to call? Where do I specify this? I

     

    By Default WCF Actions are used to specify which remore operation to call, however this is customizable according to your solution. These WCF actions can be specified using the WCF Send Adapters' Action property either through promoted properties, or the BTS.Action mapping property inside the configuration for the BizTalk WCF Send Adapter port settings inside the BizTalk Administration Console. You can specify a single action, or multiple actions based off a BTS.Operation promoted property, and let the WCF Send port do an "WCF Action" matching according to what the BTS.Operation is set to.  This can be set inside an Orchestration, or a custom pipeline component (BizTalk Translations), maybe even with maps (BizTalk transformations).

     

    should I implement the adapter in such a way that it expects a certain format (specified by me) of the messages and every application should conform to this format if it wants to communicate with the LOB? And then implement a translation of formats and parameters for every public operation in the LOB? If there are a thousand public operations in the API I need to implement a thousand translations if I want them all to be available to WCF? But then, isnt the LOB Adapter supposed to be able to display the available operations dynamically, ie. if someone adds an operation in the LOB the LOB Adapter is supposed to support it dynamically. But if I have to implement one translation for each operation, how can it be added dynamically?

     

    How you implement your adapter depends on interoperability, SOA design, Time to value, Hosting options (Besides BizTalk). From BizTalk's perspective, translation is usually done inside of pipelines, and transformations are done inside of Maps, however depending on who will eventually "Own" the adapter, you may opt to design it for the most general and adaptable use.  Adapters have the capability of metadata harvesting. In other words, the ability to query the system, in this case the LOB Application, and display a listing of "Services" or operations that can be performed every time you want to set up the adapter for use. This metadata harvesting allows for the dynamic capability. To do this each operation should have it's own message type. In the case of the WCF LOB adapters, the goal is to use WSDL and XSD's. It's up to the client to then transform, or translate the message into the correct format for the operation.  However again this is by default, you could opt to have the message format generic and have a collection of maps inside the adapter. Again this is a design question only answered by knowing you level of maintanability, interoperability, time to value, hosting and etc.

     

    HTH

    Sunday, February 10, 2008 11:36 PM
  • Dwight's answers above are absolutely on the dot. WCF action is the recommended and is the most common way to figure out which LOB operation to invoke.

     

    Just wanted to add a couple of more things about how we implemented the SAP, Siebel and OracleDB adapters on the WCF LOB Adapter SDK. We use the WCF Actions to figure out what LOB opertion the user of the adapter intends to invoke. The adapters do expect messages to be in a specific format. That does not mean that we have written a transformation for every single LOB operation. We have written a generic transformation that takes care of one class of operations - like RFCs or BAPIs or IDoc operations.

     

    Let us know how your adapter development goes.

     

    Thanks

    Monday, February 11, 2008 4:43 AM
  • Thank you so much for your replies, they really helped me out a lot!

    So basically the adapter should (in my case at least):
    *receive messages in some format that it understands
    *parse the WCF action and parameters from the message
    *translate the action and parameters into LOB specific format
    *call the corresponding remote operation with the provided parameters.

    *It should also, when creating the proxy, query the LOB for available metadata.

    But there is one final thing that is still a bit blurry. To support a dynamic number of available operations,
    *the adapter needs to query the LOB for the metadata.
    *the LOB must support metadata (and querying for these)

    But I havent found much documentation about how the adapter can utilize the ASDK for this. Are there any classes or interfaces for this purpose in the ASDK to ease development? This information is probably right under my nose but somehow I must have missed it (large amount of documentation).

    Any pointers would be much appreciated!


    Fann
    Monday, February 11, 2008 9:09 AM
  • The Echo Adapter tutorial contains a quick step through:

    http://technet.microsoft.com/en-us/library/bb798125.aspx

     

    HTH

    Wednesday, February 13, 2008 7:00 AM