I'm working on another BizTalk project, medically oriented again. This time around my job is to make a few minor changes and bring the system up for my client's customer. Pretty easy. Which leaves me and the other BizTalk developer to contemplate all the ways we can change the system around.
One aspect of the solution we don't like is its use of orchestrations. Here they aren't really doing anything but dumping a crap load of logging information. Information that could be collected via BAM.
The general pattern for our part of the system is to receive an incoming file, map it to an internal schema and pass it on to the internal systems for processing. Most of the mapping involves going to or from EDI. No biggie. The trick though is that in a few cases the same schema means different things (837 for dependents and subscribers) and the processing changes depending upon the content of the message.
Currently an orchestration queries the field that determines the type of claim and then decides how to map the message. What are our alternative methods?
Custom pipeline component
Create a disassembler that reads the message determines the type and does the mapping inside the pipeline.
Bigger Map
Combine the two maps in to one and switch mappings depending upon the field. This isn't being done because the maps are already pretty freaking huge and this would just make them....uh... huger.
Change Schema and map on the send port
Promote the field inside the schema and then create two send ports with maps and filters.
Orchestration
Already doing this and it seems a waste to spin up an orchestration just to execute an if statement containing two maps. But it is a choice.
did I miss anything? I'm skipping adapters as an arbitrary choice. It occurs to me that a scenario like this would make a decent interview question to determine how well a person knows BizTalk.