When you have EDI Batching included in your solution, some basic administrative tasks are available to you. Two options worth pointing out are:
- You can override whatever automated batch trigger you may have in place (such as a schedule or a number of records) by clicking the Override button. Clicking this button will force any queued items in a batch to be processed in full, and the output batch file to be created.
- You can see whether the batch is operational. In some cases, when certain types of exceptions occur, the underlying batch orchestration can suspend. When this occurs, you may have to manually terminate the batch via the BizTalk Administration Console’s Group Hub page. Once terminated, any queued items will process, and the batch will generate (just like clicking the Override button) and the orchestration will be deleted. In order to start a new orchestration for this batch, you will need to activate and start a new instance from the Batch Configuration screen in the Agreement’s settings.
The best thing you can do for long term visibility into your data, and ease of access for resubmissions and analysis, is to archive the data the moment it arrives. Archiving the original EDI document can be done in several ways – but in order to get it in the original format with the envelope and all of the data, you must archive it before it runs through the EDIReceive pipeline in BizTalk. This can be accomplished in several ways:
- Use a series of ports to receive the data. If, for example, your data is coming in via FTP, you could pick it up with a Receive Port that has the EDIReceive pipeline on it – which would mean you only have one port, but it would also mean that the data would be converted to XML format and validated before it could be archived (unless you use a custom pipeline – see next bullet). If you want to archive the original data in the original EDI format and not use a custom pipeline, you will need to create a Receive Port that picks up the data from the FTP site using the “PassThrough” pipeline. Next, you will need to create two Send Ports that subscribe to this. One should write the file out to an Archive directory (your archiving requirement is solved that easily!). The other Send Port should write the file out to a temporary “staging” folder. Now, you can create your final Receive Port that subscribes to this “staging” folder, picks up everything that arrives, and runs it through the EDIReceive pipeline.
- Use a custom pipeline. If you don’t want the extra hops in the previous option, or your solution doesn’t lend itself to this kind of multiple port solution, you can create a custom pipeline that writes the data to a directory. You will need to write a custom pipeline component to write the data in C# to a directory. Then, you will need to include this component along with the EDI Disassembler component (and potentially others!) to your custom pipeline. The final custom pipeline mimics the out of the box EDIReceive pipeline, but adds the extra custom component that writes the file. This is much more labor intensive, but opens up some additional options around archiving.
If the following error occurs, check the agreement state for a specific trading partner. Agreements can be enabled and disabled.
Error Reason: Agreement found for the x12 Protocol is in either Disabled or Expired state
Don’t be surprised with the amount of work involved in onboarding and testing your solution and the underlying data with your trading partner. When you initially receive the data from your partner, it could be in any format – EDI, XML, Flat File, etc. This is your first opportunity to take a look at the data and make an honest determination of how much effort is going to be involved in onboarding and testing this partner. If the data is delivered in a format that you have worked with before, and matches compliance (which is not always the case with an 837 from a partner!), then you are off to a good start – but then you will need to assess whether all of the data your system requires is available. Working with the data and doing solid analysis on the complexity of working with it is a critical first step when first working with a new partner.
Once you have done the initial development, then you step into the true testing cycle. Your development cycle may only require a week to work through, but your testing cycle can easily extend the time period to move a partner into production by weeks (or months!). As you exchange data back and forth and hammer out the details of data that is “production ready”, you’ll likely find that additional requirements crop up, or unexpected data exceptions come out. We’ll look at specific testing scenarios and likely issues that will pop up in later discussions, but the most important thing to remember is that trading partner testing (and the initial analysis of the data you will be receiving) can be a significant portion of the overall project. Be careful with your time estimations in communications with the trading partner, internal sales representatives, internal management, and especially with yourself!