The first step in onboarding a new trading partner that will be delivering inbound data to your organization is the review and validation of their inbound data. The moment you identify a trading partner that will be delivering data to you, request some sample data from them. Through analysis of this data, you will be able to determine what resourcing, timeline, and development will likely be needed in order to onboard the partner.
A trading partner may be delivering data in true EDI format (such as an 837), or in a proprietary format (CSV, XML, ECSIF, etc.), and it is critical to review this data as early in the onboarding process as possible. You will need to identify what level of work will be required to map this inbound data to a format that will work within your system. Even in cases where the trading partner will be delivering data in (for example) 837 5010 format, and your processes already accept this same format from other trading partners, there will still likely be inconsistencies in the data that will prevent you from simply accepting the data and processing it. Different organizations model their data differently, populate their EDI documents differently, and require different fields and structures. What your organization may need will likely differ from what the trading partner will – by default – be delivering.
Many organizations try to come up with a “standard timeline” for onboarding new partners – but what you will find is that every integration is unique, and while some trading partners may be able to be onboarded in a very short time, others will require a tremendous amount of development and testing in order to be ready for a production environment. The sooner you can review their data, the sooner you will be able to give an accurate estimate for the effort required to onboard them.
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.
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!