Biztalk Solution

Biztalk Solution

Post by pfeifes » Sun, 17 Jul 2005 06:27:03


Hello-

We are setting up a Biztalk Enterprise Solution and we are trying to
determine how 214 transactions will be handled.

Scenario: Our AS400 generates 214 transactions for all customers.
However, only certain customers subscribe to certain transactions.

Question: Should we filter out those 214's BEFORE they get to Biztalk
or should be let Biztalk determine whether these transactions need to
be sent or not (though Orchestration and partner codes).

Thanks for any input-

pfeifest
 
 
 

Biztalk Solution

Post by Gerrit Hul » Tue, 19 Jul 2005 04:16:45

Depends upon the desired and current situation I would say. I am working on
a project where BizTalk is intergrated with an Axapta environment. Because
Axapta contains all the data, it is easier to let Axapta deside what data to
send and BizTalk to interface that data to the outside world. This could
also apply to your AS400 situation.

The benefits in my experience of having the provider determine the data to
be send has the following benefits in the situation:
- BizTalk does not have to query any databases to do it's job
- Lesser data send for BizTalk processing (saves network bandwidth and
processing ability). Currently BizTalk is kinda the bottleneck in the
process.

In your case I recommend you to look at the current database access from
BizTalk, the load and the resources. Both options seem feasable. Do not know
what is 'best practice'.


Gerrit

 
 
 

Biztalk Solution

Post by Yossi Daha » Tue, 19 Jul 2005 21:52:15

I'd say it does really comes down to who as better access to the data that
drives the decision. but other considerations such as how easy it will be to
view and modify this configuration.

In BizTalk you may find the rules engine be very useful for this, and will
automatically provide you caching abilities, versioning etc.

Another option is to have a consuming pipeline component in the receive
pipeline to consume any messages that should not be processed (and driven by
db access or something), this is all custom code, but will reduce the load
on the BizTalk server (other then the receiving host) as messages that
should not be processed will not get persisted into the message box and no
instance of an orchestration is required)

you may be able to combine the two and call the rules engine from a the
pipeline component

Yossi Dahan