Updating Database Within Orchestration

Does your ochestration care if the DB update is successful? If not, can you code the external assembly either spawn a thread or another process so the orchestration can continue on?

Is there any way to trigger the report generation outside of BizTalk? We have a system that does something like this. Every 5 minutes a service checks to see if there are records in a table. If there are it generates and sends emails based on those records.

The prolem with external assemblies like this is you are dragging BizTalk into  other processes and is part of the reason you should avoid calling heavy processes from BizTalk. Try as much as possible to break up this big synchronous process into smaller and possibly asynchronous pieces. 

Not sure if any of this was any help or not, but hopefully it gets you thinking 🙂 

Dave,

Can I suggest that if you’re doing a lot of work in external assemblies, then maybe BizTalk isn’t the correct integration platform for your particular problem. It sort of defeats the point of BizTalk if you’re simply using the orchestration engine to call out of external assemblies, thereby losing all of the great Enterprise-y features.

If you can elaborate on why you need to do this (i.e. are you building Crystal Reports for example via their .Net API) and we may be able to offer alternatives, however I would second Gregs comment and suggest that you may need to use BizTalk to simply notify a secondary applcation (maybe a Windows Service) that reports are ready to be created, or create a custom adapter that will generate the reports as messages go through BizTalk (my current client has a similar solution where we generate PDF reports based on the message passing through the adapter).

More questions than answers I’m afraid, but possibly some food for thought.

Nick.

Dave,

my rule of thumb for what goes into an orchestration is this: if it’s a business-level item then handle it in BizTalk, if it’s lower than that then create an assembly for it. BizTalk orchestrations give you nice visibility on a process – great to see what’s happening at a high-level. BizTalk is really very heavy when it comes to testing, so write an assembly – it’s easier to test and it’s probably at a nice level to be reused. Especially if you are thinking SOA.

 Maybe Dunphy and Metwally’s quote is out of context, but on the face of it, I disagree. I’d be worried about doing extensive processing *in* an orchestration. And I am pretty sceptical about using a database adapter directly out an orchestration (although there are places where it works nicely).

It may be interesting to wonder why you are having the suspension problem. You need to call out to something that will finish relatively quickly – make BizTalk do the waiting. And only put atomic transactions round things that will finish quickly – otherwise make it long-running.

I’ve been out of commission for personal reasons for the last week so I apologize for not aknowledging the excellent advice everyone has had to offer.

It’s good to see that you are all on the same page. In fact everyone was right on when you figured out that I’m not using Biztalk as it is meant to be used. The original application was developed before my time using Biztalk 2002. Biztalk 2002 had problems with handling large files. To accomodate this a method was created whereby a “control” file is created by a web service for each incoming file type. The control file specifies which orchestration to use. Each orchestration/control file combination  differ in the steps used to process the incomfing file which is simply streamed from the file system. The usual steps are i) validate the incoming file, ii) update a database with values from the incoming file, iii) create output files and reports, iv) send the resulting files to the appropriate destination.

 In the above scenario Biztalk is used for only for 2 reasons, first as an existing service to listen for incoming files and second as a method of being able to handle new file types without rebuilding a stand alone application.

 I am aware that there are alternatives such as writing our own file listening service and perhaps using web services to provide extensibility to new file types. Nevertheless, the existing solution is up and running so we’ll likely stick with it for now.

Thanks to all for your advice.

 Dave