January 7, 2006 at 2:28 AM #12620
this is my first post on this forum, and it is rather late, so forgive me if I ramble!
I am implementing an interface using BTS2004 to convert data from our system’s proprietary format to that of one of our clients. All the basic BTS mapping processes are fine.
However, I need to do some simple data conversion on various source fields (i.e. if input value is \”a\”, change it to \”b\”, etc). For this I have an SQL database table that provides all of the mappings that are needed.
However, all of the mapping rules have not yet been provided by the client, so an element of flexibility needs to be built in to account for the fact that the values and the types of mappings wil grow over time.
The BRE seems to be the ideal mechanism to do this – I can do the database lookups, and the Composer can be used by us or the client to add new mappings as and when they are needed without needing to recompile the interface.
I also looked into the idea of long-term facts via the IFactRetriever interface, so that the Engine is not repeatedly reloading what is essentially static data.
I have implemented two different things via IFactRetriever:
(1) One that is based on a Data Connection binding: this creates an SQL connection, opens its, creates a DataConnection object from it, and Asserts it
(2) The second one was based on DataSets and DataRows, but in this case I created a separate web service to load the data up-front and then only re-load it when the data changes, and had the IFactRetriever use web methods to get and assert the data the first time the facts were needed, and then check back with the Web Service at each subsequent call by the RuleEngine to see if the data changes and, only if it has changed, to re-load and assert it (the idea being to minimise calls to the database)
HOWEVER, I have run into two big issues:
(1) I managed to get both mechanisms to work both in testing via the BRC and via orchestrations … AS LONG AS I only sent a few messages to BTS
(2) When I send a bucket-load of messages in one go (1500), both mechanisms start failing:
(a) The Data Connection one eventually says I have too many data connections open and the pool has run out (message gets rejected)
(b) The web service one fairly quickly runs out of threads (it seems a new thread is created for each web method call)
(3) I guess this is down to the number of concurrent orchestrations that BTS creates. I have played a bit with the Mgt db settings but have had no joy.
I am working on BTS2004 with SP1, VS.NET 2003, on Win 2003 Server within VM-Ware.
On this occasion I am limited to a single CPU instance of MSSQL+BTS (i.e. everything is within one VM) so I do not have any scaling options.
I am now desperate as I have been working on this on and off for two weeks trying different things …. and I need to deliver the solution next week!!!
I hope this makes sense, and I would greatly appreciate any help !!
January 7, 2006 at 9:23 PM #12621
I have resolved the problem by implementing a (perhaps less efficient but) simpler IFactRetriever that implements DataSet and DataRow. This works fine under the stress tests I mentioned. So, the urgency is gone now 🙂
However, I would still be interested to hear any thoughts regarding the unexpected results with using the DB Connection bindings and/or the web service (i.e. that BTS created so many orchestration instances that it blew either the max # db connections or max # threads in the pool).
Best regards in any case
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.