Here's the scenario:

1. flatfile arrives containing multiple loan applications (typical flatfile 
format: header, apps, trailer)
2. custom pipeline component disassembles file and creates xml messages cont
aining information from the header as well as each app (I'll call the schema
 'AppWithHeader')
3. orchestration determines the destination of each 'AppWithHeader' message 
based on business rules and sets 'DestinationParty' property of role link po
rt
4. orchestration sends message to role link port
5. custom pipeline component assembles message into original flatfile format
 (this time containing only one app)

All is well at this point. One of the possible recipients of the message, ho
wever, "needs" (wants?) to receive applications batched into larger files (l
ike the original flatfile that started the process).

Any ideas? There is no correlation between the applications in the original 
source file and the new file on the back end. For a given recipient (Destina
tionParty), the applications would be grouped based on SourceID (a field in 
the header).

Thanks in advance. I'm trying to convince the destination party that the num
ber of files shouldn't matter to them, but I may not be able to win that bat
tle.

Brian

[ Post a follow-up to this message ]

Just discovered Scott Woodgate's uniform sequential convoy sample (http://blogs.ms
dn.com/scott.../07/175391.aspx). Is a singleton orchestratio
n part of the solution?

(Also saw a post re: BT 2002 that alluded to use of a singleton orchestratio
n for this type of scenario.)

Brian

[ Post a follow-up to this message ]

The biggest problem that I see in this is that there is no built-in
functionality to batch up the documents on the outbound side, you would
need to create a process/component/application that understands the
documents and can assemble them together again.  For this to work however
you would need to be able to identify which outbound documents belong to a
specific "batch".

Larry Franks

This posting is provided "AS IS" with no warranties,and confers no rights.
Subscribe at
http://support.microsoft.com/defaul...msdn/nospam.asp
&SD=msdn
--------------------
| Thread-Topic: grouping outbound messages into a single file
| thread-index: AcRunuZNRY6qgFVYRi69N3YmypIMzA==
| X-WBNR-Posting-Host: 12.34.139.130
| From: examnotes <stonevol@newsgroups.nospam>
| Subject: grouping outbound messages into a single file
| Date: Tue, 20 Jul 2004 14:17:02 -0700
| Lines: 16
| Message-ID: <7A2BD96A-7262-430D-A1CC-966971FD7C70@microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| 	charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.biztalk.orchestration
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 127.0.0.1
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.biztalk.orchestration:7214
| X-Tomcat-NG: microsoft.public.biztalk.orchestration
|
| Here's the scenario:
|
| 1. flatfile arrives containing multiple loan applications (typical
flatfile format: header, apps, trailer)
| 2. custom pipeline component disassembles file and creates xml messages
containing information from the header as well as each app (I'll call the
schema 'AppWithHeader')
| 3. orchestration determines the destination of each 'AppWithHeader'
message based on business rules and sets 'DestinationParty' property of
role link port
| 4. orchestration sends message to role link port
| 5. custom pipeline component assembles message into original flatfile
format (this time containing only one app)
|
| All is well at this point. One of the possible recipients of the message,
however, "needs" (wants?) to receive applications batched into larger files
(like the original flatfile that started the process).
|
| Any ideas? There is no correlation between the applications in the
original source file and the new file on the back end. For a given
recipient (DestinationParty), the applications would be grouped based on
SourceID (a field in the header).
|
| Thanks in advance. I'm trying to convince the destination party that the
number of files shouldn't matter to them, but I may not be able to win that
battle.
|
| Brian
|
|

[ Post a follow-up to this message ]