A unified B2B integration architecture eliminates the need for distributing different B2B integration functions across multiple disparate systems. In other words you no longer need a different tool to support EDI transactions and another tool for handling application integration and another tool for routing transactions to workflow tasks for human interaction, all of these functions are supported in a single platform.
Our data integration architecture also allows you to handle all types of data conversions with business rules. With a single platform you can onboard customer EDI data faster by up to 80% as well as integrate with SAP and other ERP systems.
Adeptia is the only application that combines B2B transactions handling with rich workflow capability. Workflows allow for routing data exceptions to human interaction tasks that require review and correction of the data before processing the transaction. Workflows are also important to have your customers or your business team to be able to access and fix their data errors through a secure web form and allow them to resubmit the corrected data for processing. Adeptia's B2B gateway architecture solution is a business application that allows business teams to setup customer onboarding quickly that results in reduce costs and less reliance on IT.
Here's a diagram depicting a typical EDI Trading Partner setup workflow that can be automated in Adeptia.
(A sample EDI Trading Parnter setup process automated in Adeptia)
Adeptia provides a unified platform that support all the protocols, data formats, standard data dictionaries, and it contains a robus b2b gateway architecture , efficient data transformation and process engine to convert and route data to any target application.
Adeptia accepts most recognized file formats such as EDI, XLS, XLSX, XML, HIPAA, HL7, Flat Files, and JSON formats. It includes a library of industry-standard formats such as EDI, EDIFACT, ODETTE, MISMO, and ACORD etc. Within each industry-standard, Adeptia provides all the different versions that have been released for the particular standard.
Users can also make customizations to the standards and make copies of those modified standards. This is needed in case, for example, when a customer is using a 5010 EDI 850 but has added custom segments or fields. The data formats can change over time as customer may send an XML file instead of a standard EDI file. Thus providing the business users an easy setup screen, where they can easily map the incoming data to a pre-defined output format, is important.
A business-centric user setup interface allows less dependence on IT and the business team becomes self-reliant in handling all the data variations that can occur as part of the data exchange with the trading partner. This reduces information technology costs and increases their productivity by having IT focus on governance role instead of the operational role.
Another key point is that for non-EDI, the business team can identify specific column as Partner ID or Order ID that can be tracked and shown as part of the B2B transaction logs. Key takeaway for non-EDI transaction processing is to have the transaction logs show similar process history similar to EDI logs where the transactions can be searched easily with user-defined fields such as Order ID, Transaction ID, Customer Number or Partner ID.
Customer services team also needs visibility on the entire lifecycle of the EDI transaction not only the EDI translation in the B2B integration solution but also what happens to this data when it gets loaded into external systems such as SAP. Within the Trading partner setup, user can also define Application ID of the customer that exists in SAP. This allows linkage of inbound/outbound EDI data with the subsequent transaction processing that occurs in SAP. By providing external referential IDs of customers in your B2B Trading Partner setup helps to trace the status of an Order in external systems and thus provides a “single source of truth” for the particular transaction.
As an example, when an EDI 850 Purchase Order is processed and the data is loaded into the ERP for order fulfillment, customer services team can look at the B2B logs and see the status of the fulfillment, issuance of an invoice, generation of advanced shipment notice and other relevant data points that exist in these external applications and all of this information is available in the Adeptia B2B Transaction monitoring dashboard.
Visibility of data is key to Adeptia’s B2B Integration architecture where greater emphasis is given on real-time monitoring and tracking of both inbound and outbound transactions.
Real-time visibility offered by Adeptia’s b2b gateway architecture makes it easy for your customer services team to respond to trading partners quickly with the right information, such as:
B2B solution can also organize Message level logs based on Inbound and outbound relationships. This feature allows user to select a B2B relationship and then view all Transaction sets processed using that relationship. In this view transaction set level detail like Order ID can be displayed and directly searched.
For a reliable EDI communication, Adeptia’s data integration architecture provides support for a wide variety of protocols such as AS2, SFTP, JMS, Email, API, etc. Protocol support for AS2 includes easy management of certificates and secure communication with your trading partners. AS2 file transmission logs are consolidated within the B2B monitoring so that all the inbound/outbound file transfer status information is shown as part of a unified B2B monitoring dashboard. The dashboard also has links to the actual raw file, the output data, process status and it includes the acknowledgment status of the EDI transmission.
Similarly the SFTP support includes the ability to poll data files in a particular location and user can configure the polling frequency in terms of how often the files need to be fetched. By providing wild card expressions, solution automatically picks up all the files from the source path that meets these file pickup conditions. One polling event can be used for multiple trading partners and when the files are pulled by the system it automatically identifies which partner data relationship to execute in order to process the incoming EDI files.
In terms of generating outbound EDI files, the source data can be extracted from a database. Thus the solution supports JDBC connectivity with any relational database. Adeptia provides the connectors for all the major databases such as MySQL, Sql Server, Oracle, and DB2. In addition to these databases, Adeptia also provides connectors for Mongo, Cassandra, Redshift, and Elastic Search.
Cloud file repositories are being widely used for storing files as part of archiving EDI data or storing the converted data as part of the EDI transmission. Amazon S3 and Azure BLOB are cloud based storage that Adeptia can easily connect with and can perform the different functions such as placing files, picking files and deleting files in those locations.
EDI messages can also be sent as payloads through an API. For example, customer may encode the EDI in a SOAP message or send a file through REST API as a multi-part file. In Adeptia you can design a pre-process flow that can take the incoming payload and extract the EDI data from the request message and send it to for translation and integration with backend applications. Ability to define your own orchestration and publish it as SOAP or an API endpoint for your customers to transmit EDI data through a web service call as a synchronous call is one of the key features of the Adeptia data integration solution. Adeptia combines B2B EDI message handling and API orchestration in a single platform. Similarly you can also reverse the process where a customer can call an API method published in Adeptia such as “GetInvoiceEDI” and pass some parameters in the request such as Customer ID, Order ID and receive an EDI 810 payload as a web service response.
We have described the benefits of our Trading Partner Management interface which helps in setting up trading partner profiles, data translation relationships for inbound and outbound messaging, and a central repository to manage all your customer data services such as layouts, mappings and translation routing rules for EDI and non-EDI files.
In this section we will cover some of the key architectural aspects of the Trading Partner Management portal.
Shown above is the Trading Partner Management Portal architecture and it consists of following components:
Centralized service repository allows users during design-time to select from the existing list of available services such as schema definitions, message transport, application connections and workflows to automate a data exchange with a trading partner.
Service repository is also tied to some of the important underlying features that are important in managing the services in the long run. Components such as Versioning, as described earlier, help to maintain different versions of the same service. Impact Analysis shows the list of dependent services that would be affected if changes are made to a schema or a mapping. Dependencies help you to think through how a change in any one of the services would impact the runtime behavior of a message translation or integration of that message with the backend systems.
Documentation of services is one of the important characteristics of Adeptia’s collaborative B2B architecture. Customer teams can document the high-level message translation rules that the development team can use in implementing the mapping or the orchestration.
Final component of the Adeptia B2B gateway architecture that we would now focus on is the ability to create rich orchestrations to handle complex B2B data exchange scenarios. For example, an incoming EDI may require a “hold” if supplemental information about Patient’s Claim is not available during the time of the EDI 837 transmission. This would require your team to build a pre-process flow to first check if all the required information is sent along with the EDI 837 and if it is confirmed that all the information is present only then send the EDI message for translation.
In the below diagram we are showing an example of using a pre or post process steps as part of your B2B data exchange.
Service orchestration is not restricted to pre-process, you can also think about using only the process flow approach especially in cases where partner validation is not needed. In scenarios where a clearinghouse is processing claims, the need for validation by routing the message through a partner profile is not necessary since those rules are already in place between the service provider and its client. In this case, building a dynamic process to handle all types of EDI messages regardless of which partner is sending them makes more sense.
Adeptia offers both Cloud and On-Premise deployment options. Please contact Sales to discuss your B2B/EDI integration deployment needs. Below is a sample SaaS cloud deployment model for Adeptia B2B application integration solution.
The Adeptia Solution is a proven product that has been deployed by Fortune 500 companies who are utilizing it for various mission-critical solutions. It provides enterprise-class scalability and performance using a streamlined data integration architecture to enable customers very high volumes of messages with high precision and speed. AIS can be installed in a clustered mode for scaling performance and for redundancy or failover. Adeptia also provides the automatic ability to send notifications and alerts, view runtime status of all the transactions, recover failed transactions, and archive messages.
Taking the above points into context we will list the key benefits of Adeptia’s data Integration architecture:
To learn more about Adeptia, check out: