|
Home > Archive > BizTalk Server Orchestration > May 2005 > Best Practice question: receive port -> send port -> orchestration
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Best Practice question: receive port -> send port -> orchestration
|
|
| Dan Tharp 2005-05-19, 5:50 pm |
| I have a "best practice" question:
Here's what I need to do:
Various trading partners supply us with non-XML files which need to be
mapped into a common/standard XML file to then be submitted to an
orchestration which will, in turn, submit the mapped XML document to a web
service (which will actually do all of the business processing for importing
the data into a database and etc.)
So, here's what I have setup in my project:
- A flat-file schema for each trading partner's data (one schema for each
trading partner)
- A common schema for the XML file that all flat-files are to be mapped to
- A map for each flat file -> XML file combination (one map for each trading
partner)...all data getting mapped to the common XML file
- A receive pipeline (flat-file disassembly) for each flat-file to be
expected (one per each trading partner)
In BizTalk explorer, I've created:
- A receive port/receive location combination for each flat-file, with the
appropriate pipeline specified on the receive location and the appropriate
inbbound map specified on the receive port
- A single send port (file) which has a filter listing each of the receive
ports:
BTS.ReceivePortName == (ReceivePortA) and BTS.ReceivePortName ==
(ReceivePortB) and .....etc...
....so that all flat-files dropped off from these trading partners will get
picked up, mapped using the appropriate map to the same XML format, and
routed to the same outbound directory.
The end result (regardless of what trading partner or flat-file format
things started from) is a whole slew of XML files that are all the same
format, all in the same directory.
All of this works fine and dandy.
My next step is to create an orchestration that takes these commonly
formatted XML files and push them into an already written web service which
will then do all of the business processing (updating databases and etc.).
My question is, should I:
1) Continue to drop the mapped XML files into a common directory, where the
orchestration will pick them up and pass them off to the web service, or
2) Is there a way to push the XML files directly to the orchestration,
without having to drop them off into a directory first.
Is there a way to get the orchestration to pick these files up directly,
rather than from a directory?
And/or: Is it "better" just to do the file drop/pickup approach anyways?
Thanks!
Dan
| |
| Jeff Lynch 2005-05-19, 5:50 pm |
| I haven't tested this using Web Services but you should be able to create a
single send port using the new BizTalk Adapter for Web Services Enhancement
(WSE) 2.0 or the existing SOAP Adapter to "call" the web service you need
to submit these document to. This send port can "subscribe" to your receive
ports and do the outbound mapping as well. This eliminates the need for an
orchestration.
--
Jeff Lynch
"A BizTalk Enthusiast"
http://codebetter.com/blogs/jeff.lynch
"Dan Tharp" <dtharp@NOSPAMPLEASEgdtr.com> wrote in message
news:uV9YWmIXFHA.3320@TK2MSFTNGP12.phx.gbl...
>I have a "best practice" question:
>
> Here's what I need to do:
>
> Various trading partners supply us with non-XML files which need to be
> mapped into a common/standard XML file to then be submitted to an
> orchestration which will, in turn, submit the mapped XML document to a web
> service (which will actually do all of the business processing for
> importing the data into a database and etc.)
> So, here's what I have setup in my project:
>
> - A flat-file schema for each trading partner's data (one schema for each
> trading partner)
> - A common schema for the XML file that all flat-files are to be mapped to
> - A map for each flat file -> XML file combination (one map for each
> trading partner)...all data getting mapped to the common XML file
> - A receive pipeline (flat-file disassembly) for each flat-file to be
> expected (one per each trading partner)
>
> In BizTalk explorer, I've created:
> - A receive port/receive location combination for each flat-file, with the
> appropriate pipeline specified on the receive location and the appropriate
> inbbound map specified on the receive port
> - A single send port (file) which has a filter listing each of the receive
> ports:
> BTS.ReceivePortName == (ReceivePortA) and BTS.ReceivePortName ==
> (ReceivePortB) and .....etc...
> ...so that all flat-files dropped off from these trading partners will get
> picked up, mapped using the appropriate map to the same XML format, and
> routed to the same outbound directory.
> The end result (regardless of what trading partner or flat-file format
> things started from) is a whole slew of XML files that are all the same
> format, all in the same directory.
>
> All of this works fine and dandy.
>
> My next step is to create an orchestration that takes these commonly
> formatted XML files and push them into an already written web service
> which will then do all of the business processing (updating databases and
> etc.).
>
> My question is, should I:
> 1) Continue to drop the mapped XML files into a common directory, where
> the orchestration will pick them up and pass them off to the web service,
> or
> 2) Is there a way to push the XML files directly to the orchestration,
> without having to drop them off into a directory first.
>
> Is there a way to get the orchestration to pick these files up directly,
> rather than from a directory?
>
> And/or: Is it "better" just to do the file drop/pickup approach anyways?
>
> Thanks!
> Dan
>
>
>
| |
| Yossi Dahan 2005-05-20, 7:49 am |
| Jeff, Dan
I thought calling a web service from BizTalk without Orchestration is not
supported. if you know otherwise Jeff I'd love to hear. I was sure you
cannot simply set a send port to use the SOAP/WSE adapter outside an
orchestration.
If I'm wrong about this, can you provide a little more details about this?
On the other hand, if I'm not missing anything, I think the solution can be
simplified, you don't actually need the send port.
Can't you have the FFDisassembler use the flat file schemas convert the
message to xml and then use the mapping potion in the receive pipeline to
convert the xml representation of the flat file to the generic XML? doing so
you can then have you orchestration subscribe to this send port and do its
work and not have to go through the file system (or any other temporary
storage)
You might even consider to take another route -have a single pipeline to
parse all the flat file types. this can be achieved by wrapping the
FFDisassembler and using custom code to identify the flat file type or by
using a "smarter" disassembler such as Itemfield's ContentMaster
Hope this helps
Yossi Dahan
"Jeff Lynch" <jeff.lynch@newsgroup.nospam> wrote in message
news:e9J2RpJXFHA.2520@TK2MSFTNGP09.phx.gbl...
>I haven't tested this using Web Services but you should be able to create a
>single send port using the new BizTalk Adapter for Web Services Enhancement
>(WSE) 2.0 or the existing SOAP Adapter to "call" the web service you need
>to submit these document to. This send port can "subscribe" to your receive
>ports and do the outbound mapping as well. This eliminates the need for an
>orchestration.
>
> --
> Jeff Lynch
> "A BizTalk Enthusiast"
> http://codebetter.com/blogs/jeff.lynch
>
>
> "Dan Tharp" <dtharp@NOSPAMPLEASEgdtr.com> wrote in message
> news:uV9YWmIXFHA.3320@TK2MSFTNGP12.phx.gbl...
>
>
| |
| Jeff Lynch 2005-05-20, 5:58 pm |
| The BTS2004 WSE Adapter help file indicates that you can use this in
"messaging-only" scenarios using a send pipeline. I'm not currently doing
any Web Services development work so I haven't tried this out yet. Perhaps
someone from MS can clarify?
--
Jeff Lynch
"A BizTalk Enthusiast"
http://codebetter.com/blogs/jeff.lynch
"Yossi Dahan" <yossidahan@hotmail.com> wrote in message
news:%2344ckjTXFHA.580@TK2MSFTNGP15.phx.gbl...
> Jeff, Dan
>
> I thought calling a web service from BizTalk without Orchestration is not
> supported. if you know otherwise Jeff I'd love to hear. I was sure you
> cannot simply set a send port to use the SOAP/WSE adapter outside an
> orchestration.
> If I'm wrong about this, can you provide a little more details about this?
>
> On the other hand, if I'm not missing anything, I think the solution can
> be simplified, you don't actually need the send port.
>
> Can't you have the FFDisassembler use the flat file schemas convert the
> message to xml and then use the mapping potion in the receive pipeline to
> convert the xml representation of the flat file to the generic XML? doing
> so you can then have you orchestration subscribe to this send port and do
> its work and not have to go through the file system (or any other
> temporary storage)
>
> You might even consider to take another route -have a single pipeline to
> parse all the flat file types. this can be achieved by wrapping the
> FFDisassembler and using custom code to identify the flat file type or by
> using a "smarter" disassembler such as Itemfield's ContentMaster
>
> Hope this helps
>
> Yossi Dahan
>
> "Jeff Lynch" <jeff.lynch@newsgroup.nospam> wrote in message
> news:e9J2RpJXFHA.2520@TK2MSFTNGP09.phx.gbl...
>
>
| |
| Matt Milner 2005-05-20, 5:58 pm |
| Create one receieve port with many receieve locations. put all of your maps
on the receive port (it will pick the right one based on input message type)
and then bind your orchestration receive to the receive port. That should
take care of it for you.
Matt
"Dan Tharp" <dtharp@NOSPAMPLEASEgdtr.com> wrote in message
news:uV9YWmIXFHA.3320@TK2MSFTNGP12.phx.gbl...
>I have a "best practice" question:
>
> Here's what I need to do:
>
> Various trading partners supply us with non-XML files which need to be
> mapped into a common/standard XML file to then be submitted to an
> orchestration which will, in turn, submit the mapped XML document to a web
> service (which will actually do all of the business processing for
> importing the data into a database and etc.)
> So, here's what I have setup in my project:
>
> - A flat-file schema for each trading partner's data (one schema for each
> trading partner)
> - A common schema for the XML file that all flat-files are to be mapped to
> - A map for each flat file -> XML file combination (one map for each
> trading partner)...all data getting mapped to the common XML file
> - A receive pipeline (flat-file disassembly) for each flat-file to be
> expected (one per each trading partner)
>
> In BizTalk explorer, I've created:
> - A receive port/receive location combination for each flat-file, with the
> appropriate pipeline specified on the receive location and the appropriate
> inbbound map specified on the receive port
> - A single send port (file) which has a filter listing each of the receive
> ports:
> BTS.ReceivePortName == (ReceivePortA) and BTS.ReceivePortName ==
> (ReceivePortB) and .....etc...
> ...so that all flat-files dropped off from these trading partners will get
> picked up, mapped using the appropriate map to the same XML format, and
> routed to the same outbound directory.
> The end result (regardless of what trading partner or flat-file format
> things started from) is a whole slew of XML files that are all the same
> format, all in the same directory.
>
> All of this works fine and dandy.
>
> My next step is to create an orchestration that takes these commonly
> formatted XML files and push them into an already written web service
> which will then do all of the business processing (updating databases and
> etc.).
>
> My question is, should I:
> 1) Continue to drop the mapped XML files into a common directory, where
> the orchestration will pick them up and pass them off to the web service,
> or
> 2) Is there a way to push the XML files directly to the orchestration,
> without having to drop them off into a directory first.
>
> Is there a way to get the orchestration to pick these files up directly,
> rather than from a directory?
>
> And/or: Is it "better" just to do the file drop/pickup approach anyways?
>
> Thanks!
> Dan
>
>
>
|
|
|
|
|