none
Designing BTARN Business Process RRS feed

  • Question

  • Hi All,

    We are running Windows Server 2008 R2 Standard with BizTalk Server 2009 Standard.  Database is SQL Server 2008 R2 Standard.  Accelerator is BTARN 3.5.

    We have a requirement to utilize RNIF messaging to exchange business documents on behalf of our customers and a third-party platform, essentially acting as a hub.  We already have a process in place which generates the document (service content) and attachments (payload) which we could use for the RNIF message.  The process which generates this content does not use BizTalk and for the time being, if possible, we'd like to keep it that way.

    BizTalk is a completely new product for us and we have been working our way through the tutorials and documentation for both BizTalk and BTARN.  The disconnect (for us) is designing the business process we require.  We've gone through and set up the agreements and trading partners in BTARN configuration, and using the provided LOB application would seem to provide the functionality we'd need (we haven't tested with the trading partner as of yet as we want to be closer to completion than we currently are prior to testing).

    At this point the easiest route would seem to be dropping the service content and payload into a folder on the BizTalk Server and having a receive location configured with a FILE adapter that picks up the files, creates an RNIF message and sends it off.  Eventually we'd like to use the SQL adapter and have BizTalk create the service content and payload, but at this time we are just trying to add BizTalk to the current process where appropriate.

    Now, if my assumptions about how this can (not necessarily should) work aren't very far off, and the experts out there view what I'm wanting to do as possible - and fairly straightforward, this is where I'm unsure as to how to proceed.  Can anyone set me on the path forward?  Steps to complete?

    Any suggestions are greatly appreciated!

    Best Regards
    Brad
    Thursday, August 22, 2013 4:50 AM

Answers

  • Reminder:  This is from memory.

    BTARN Attachments are handled with Muli-Part Messages, which the File Adapter doesn't support.  It works form the LOB tables because of some coordination between the SQL Receive and the pipeline components which actually make the Multi-Part Message in the Pipeline.

    So, absolutely can create your own Multi-Part Messages from files if you can correlate the RN Message with it's attachments.  Then route it to your Business Process.

    • Marked as answer by Pengzhen Song Wednesday, August 28, 2013 11:41 AM
    Friday, August 23, 2013 12:50 PM

All replies

  • First, you're actually understanding pretty well.  BTARN takes a bit to get accustomed to, relative to other BizTalk concepts or add-ons.  That's just how it's implemented.

    IIRC, the documented input/output for the Accelerator parts is the LOB tables (don't recall exactly what they're called) which actually is a bit disconnected form 'normal' BizTalk processing.

    However, if you consider the Orchestrations as templates, you can modify them to remove the table interaction and substitute your own processing.  I think there's even a comment somewhere that says as much.

    Thursday, August 22, 2013 12:45 PM
  • Hi boatseller,

    Thanks for the response, it's nice to know I'm on the right track.  With regard to the FILE adapter, I was doing a bit more reading on message processing in BTARN, specifically SQL processing in BTARN and I came across the following:

    "You can choose to use a File adapter to submit service content to BTARN, instead of using the default SQL adapter. If you choose to use a File adapter, BTARN does not support attachments."

    This would seem to put an abrupt end to my designs as the inclusion of attachments in our solution is a definite requirement.  Would you have any suggestions as to a different approach to my problem?

    Thanks!

    Friday, August 23, 2013 12:42 AM
  • Reminder:  This is from memory.

    BTARN Attachments are handled with Muli-Part Messages, which the File Adapter doesn't support.  It works form the LOB tables because of some coordination between the SQL Receive and the pipeline components which actually make the Multi-Part Message in the Pipeline.

    So, absolutely can create your own Multi-Part Messages from files if you can correlate the RN Message with it's attachments.  Then route it to your Business Process.

    • Marked as answer by Pengzhen Song Wednesday, August 28, 2013 11:41 AM
    Friday, August 23, 2013 12:50 PM
  • Hi boatseller,

    I think I'm finally beginning to understand how this whole thing works.  The base configuration applied to the product adds the default send and receive ports and pipelines I would need.  If I wanted to modify the behaviour of any component (such as modifying the Orchestration to start the process from a file rather than the MessagesFromLOB table) is when I would need to create (or modify) and deploy a solution through Visual Studio.  If however I were to replicate the behaviour provided in the LOB application then I should have everything I need right out of the box.

    The reason I ask is that this all still seems to be quite a bit over my head and rather than trying to re-invent the wheel I think I might have an easier time tying in the appropriate BTARN classes into my application and calling them from there (if that's even possible, though I think that's a separate question better posed in a different forum).

    Is my thinking here correct?
    Wednesday, August 28, 2013 3:30 PM
  • So, I don't think you can just use BTARN completely out of the box.  At least you have to copy and deploy the template Orchestration for each of transaction types you intend to use.

    That's all covered in the Sample and IIRC, the customization is very minimal.  It will then pull and push message to/from the LOB tables.

    If you wanted to change that behavior, you could then continue to modify the transaction's handler Orchestration to work however you need.

    Wednesday, August 28, 2013 6:17 PM