Technologies: .net WebServices | Windows Applications | Boomi | X12: 204,214,210,990,997
EDI : Electronic Data Interchange - While organizations have been following a given set of "standards" for decades - it seems that everyone has their own interpretation - or set of expectations surrounding these standard document exchanges. In my experience in the transportation industry this was for years a constant pain in our business model. We were constantly fighting one off solutions for specific customers asking for changes that did not fit into our mold. The result from years of this behavior was an unstable and often broken model that resulted in loss of partner confidence. Considering the rapid expansion we were experiencing in this area, we arrived at a simple decision that our existing interface model would not sustain the organization and that an entire re-auth of the process was in order.
After research and discussion with our TMS provider (TMW) it became clear to us that the distributed nature of how we conduct business would not fit well with their off the shelf solution. We needed granular control presenting and restricting access (and actions) within a diverse set of organizational units. We needed to present our end users with dynamic mappings and notifications of business partner data, and we needed a set of flexible schemas to control the data exchange path in and out of our environment.
Our elected path was to begin with a schema for the exchange of data in and our of our environment. It may seem obvious, but the markup of choice we landed on was XML. In conjunction with the design of the schema we worked out a model for the API. The API for the creation and extraction of data in our environment would need to be highly modular - with a flexible set of options that would be enforced on a profile level. By designing an API that started with configurable profiles we were able to conditionally enforce how we wanted the API to interact with specific partner data. The end result of this model was that functionality could be added as partner demand changed without influencing the process models we presently had in place. An additional benefit of this model was that we could begin employing the API with one partner and work forward implementing all of the custom code (as profile options) as we came to the partner in a migration plan.
The API was built and implemented as a .net WebService for a several reasons.
- We dreamed of a day when the data exchange mechanisms of our partners would mature beyond the latent ftp file based exchanges we were accustomed to. By starting with a public facing web service that was securable/configurable by partner we were building an infrastructure, that given the right interface opportunities would put us ahead of the competition.
- We knew there would be a set of user interface tools that provided easy interaction with this partner data and the web based API made the evolution of these user interfaces much simpler.
- We knew there were projects in the works around the idea of load tracking that would fit very nicely into the security model we were working toward, and that exposing these methods in this way would reduce the programming required to make those interfaces a reality.
The user interfaces for this project were primarily focused on the accept/reject functionality of load tendering. The user interfaces were designed to be driven by organization units with configurable access and display options per unit. These interfaces were written in vb.net and were fairly customizable, which afforded us a shorter time to deploy partner integrations as well as flexible delegation of authority.
Additional applications and services were developed that facilitated extensive activity logging, custom email notification and XPath configurable message indexing (for UI search). For document mapping and transfer we elected to partner with Boomi using their customer premise solution - Integration Platform. The Boomi solution afforded us the opportunity to interface using practically any transport and any source format.
This project is very much still a work in progress because our list of business partners continues to grow, but the it is fair to say that we have made great strides forward in our ability to rapidly integrate with any business partner using most any transport and file exchange format. This flexibility has translated into increased opportunities for customer service and satisfaction. If you are interested in learning more about this or any other project please contact me.