We are about to design our 1st BizTalk Interface. The issue I am having is t
o
decide what should be a message. (ie what is the business object).
.
In our situation, we have a 3 entites in our source database. Entiry A can
be made up Entity B, and Entity B is a use of Entity C. In real world
examples.
A= Configuration (CD)
B = Track
C = Recording
.
The questions is do we always send accross the Configuration, which is made
up of many tracks, which need information from recording.
.
Therefore if a element of recording changes then we would need to send the
whole configuration.
.
The destination is a mainframe system, which expects a flat file, of mutiple
records (track and recording information). For a configuration, it expects 1
record to represent the configuration and then the rest of records to
represent the tracks. So for a 10 Track Configuration it expects 11 records.
.
I ma trying to gigure out what is the best design with BizTalk in mind,
.
Any help would be great.
.
Derek.

[ Post a follow-up to this message ]

Hmmm, I'm not sure that there is enough information here to make a
recommendation...
But I will say that, in general, sending complete documents rather than
"deltas" (i.e. just changes) can make life easier in many ways, barring some
reason that makes it impractical.

Scott Colestock
www.traceofthought.net


"Derek" <Derek@discussions.microsoft.com> wrote in message
news:370AB275-73DC-4976-A95A-8462F618D2F0@microsoft.com...
> We are about to design our 1st BizTalk Interface. The issue I am having is
> to
> decide what should be a message. (ie what is the business object).
> .
> In our situation, we have a 3 entites in our source database. Entiry A can
> be made up Entity B, and Entity B is a use of Entity C. In real world
> examples.
> A= Configuration (CD)
> B = Track
> C = Recording
> .
> The questions is do we always send accross the Configuration, which is
> made
> up of many tracks, which need information from recording.
> .
> Therefore if a element of recording changes then we would need to send the
> whole configuration.
> .
> The destination is a mainframe system, which expects a flat file, of
> mutiple
> records (track and recording information). For a configuration, it expects
> 1
> record to represent the configuration and then the rest of records to
> represent the tracks. So for a 10 Track Configuration it expects 11
> records.
> .
> I ma trying to gigure out what is the best design with BizTalk in mind,
> .
> Any help would be great.
> .
> Derek.

[ Post a follow-up to this message ]

Thanks Scott
That answers part of my design...the other part I am struggling with, si
should a message be the complete configuration or should I design it at the
track level; ie. if a configuration changes..I transmit mutiple mesasages ..
a message that represents the configuration and a message for each track. I
am trying to stay way from FAT messages.

Derek.

"Scott Colestock" wrote:

> Hmmm, I'm not sure that there is enough information here to make a
> recommendation...
> But I will say that, in general, sending complete documents rather than
> "deltas" (i.e. just changes) can make life easier in many ways, barring so
me
> reason that makes it impractical.
>
> Scott Colestock
> www.traceofthought.net
>
>
> "Derek" <Derek@discussions.microsoft.com> wrote in message
> news:370AB275-73DC-4976-A95A-8462F618D2F0@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]

Well, to help make this decision, you might consider whether using multiple
messages will necessitate convoy processing in a resulting orchestration,
and whether that will be desirable or not.

Scott Colestock

"Derek" <Derek@discussions.microsoft.com> wrote in message
news:98C56320-35D0-49FC-901D-EC6346F180EE@microsoft.com...[vbcol=seagreen]
> Thanks Scott
> That answers part of my design...the other part I am struggling with, si
> should a message be the complete configuration or should I design it at
> the
> track level; ie. if a configuration changes..I transmit mutiple mesasages
> ..
> a message that represents the configuration and a message for each track.
> I
> am trying to stay way from FAT messages.
>
> Derek.
>
> "Scott Colestock" wrote:
> 

[ Post a follow-up to this message ]

Hi,

its also worth noting "What" are you sending. Is a single document
with A,B,C really the functionality, or is this purely the data?

I would consider writting something that encapsulates the A,B,C
(optionals now). The encapsulating element now becomes the indicator
to "what type of message" you're sending, not the content you are
storing.

Hope this helps,

Marvin Smit.


On Tue, 23 Aug 2005 13:01:24 -0500, "Scott Colestock"
<scolestock@community.nospam> wrote:

>Well, to help make this decision, you might consider whether using multiple
>messages will necessitate convoy processing in a resulting orchestration,
>and whether that will be desirable or not.
>
>Scott Colestock
>
>"Derek" <Derek@discussions.microsoft.com> wrote in message
>news:98C56320-35D0-49FC-901D-EC6346F180EE@microsoft.com... 
>

[ Post a follow-up to this message ]