Whitepaper. Boomi Integration Platform v Introduction and Technical Overview

Transcription

1 Whitepaper Boomi Integration Platform v3.3.0 Introduction and Technical Overview `` Boomi, Inc. 801 Cassatt Road, Suite 120 Berwyn, PA ph fx

2 Page 2 of 18 Table of Contents Introduction... 3 Business Integration... 3 Boomi's Approach to Business Integration... 4 Platform Architecture... 4 Overview... 4 Fault Tolerance... 5 Load Balancing... 5 Data Persistence... 5 Platform Configuration... 5 Zero-Install Client... 6 Product Maintenance... 6 Integration Platform Components... 6 Process Designer... 6 Document Queues... 8 Business Document Framework...9 Common features of Business Document Adapters...9 Business Adapter Framework...10 Common features of Business Adapters...10 Database Integration...11 Transport Adapter Framework...11 Common features of Transports...11 Using the Boomi Integration Platform...12 IP Designer: Building Integration Processes...12 Integration Projects...13 Explicit Error Handling...14 IP Manager: Monitoring and Administration...14 The Complete Integration Process...14 Step-by-Step Sequence...14 Example: Inbound Shipment Order...16 Example: Customer Data Synchronization...17 Conclusion...17

3 Page 3 of 18 Introduction The Boomi Integration Platform is a next-generation technology designed as a complete solution for business integration. The platform was designed for both application integration and business-to-business integration. The processes required to enable these integration points are setup and managed through a visual modeler, and the services that execute these processes can be deployed from one to many nodes to scale to meet the needs of diverse enterprises. The purpose of this document is to provide an introduction into the architecture and technical features available in the Boomi Integration Platform. Additionally, it includes a brief overview of the difficulties facing the business integration market today and how Boomi addresses those problems. Business Integration The Business Integration marketplace exists based on the core principle that businesses: (i) can no longer afford to keep internal applications independent from one another; (ii) must automate the exchange of information with their business partners; and (iii) cannot natively interface their various enterprise applications with each other. Therefore, a class of software technology must be designed exclusively to enable this type of connectivity and exchange of information. This software technology is known as business integration software. The value proposition of business integration increases as the number of software applications and business partners of a particular company grows. Further, the value proposition increases as the time spent automating these various integration points is reduced. Take for example the warehouse that needs to handle the electronic exchange of shipment orders and acknowledgments with its customer. The sooner the warehouse can complete this project, the sooner the warehouse and its customer can proceed with their business relationship. This is one of many examples that drive integration solution initiatives. Business-to-business integration (B2Bi) is defined as the set of technologies that enable the automated, electronic exchange of information between a business and it trading partners. There are hundreds of standards in existence today that offer various types of strategies for streamlining this exchange of information electronically. In an attempt to simplify this exchange, this proliferation of standards has instead complicated the marketplace. Take for example the previous warehouse scenario. As the business grows and changes, they may be forced to accept and generate ANSI X12 EDI documents from Customer A, RosettaNet PIP s with Customer B, and EDIFACT documents with Customer C. Suddenly the IT infrastructure of the warehouse becomes increasingly complex as the various standards are implemented. In contrast, application Integration comprises those technologies that enable an automated exchange if information between internal enterprise applications. Today the majority of application integration projects are accomplished by writing code to make a point-to-point connection between applications as needed. This is a lengthy, error-prone process, and the complexity of this approach increases exponentially as more and more point-to-point interfaces are built. And to make matters worse, 12 to 14 months later when these interfaces must be modified, the code must be learned again by a new resource. This is not a scalable approach.

4 Page 4 of 18 Boomi's Approach to Business Integration Boomi has identified the following critical design points that help to create the foundation on which the Boomi Integration Platform is built: Complete solution. The solution must consist of all components required to connect internal applications together and provide all components required to connect applications between a company and its business partners. Minimal software development. To the extent possible, the solution must minimize or eliminate the need to develop application code to enable integration. Instead common integration patterns are implemented through a configurable process designer to expedite setup and maintenance of integration points. Platform durability. Proper data persistence and retry capabilities must exist. Without the redundant logic of a persistent infrastructure in place, data can be lost when issues occur. The assumption that connectivity will always be successful or available creates many problems and is alleviated with proper data persistence. Data transformation is the core of integration. Application A s definition of the data fields that make up a product, purchase order, inventory report, or countless others, are almost always different than Application B s definition. Likewise, Company A s invoice or advance shipment notice is represented differently than Company B s. A constant need exists to transform one document format to another in the process of successful integration. Data transformation is typically the most complex and time-consuming part of the integration project. Standards support. Many standards exist today to describe the exchange of business documents in an electronic manner. These standards must be simple to define and implement, thereby minimizing the lead time required to complete the integration project. Applications support. A true end-to-end integration solution must provide access to data and/or server layers of the related applications. Connectivity to a business application must be straightforward to setup and maintain. Platform Architecture Overview The Boomi Integration Platform consists of a collection of distributable services that implement the various platform functionalities. Two client interfaces are also included to handle system design and administration. All configuration settings are stored in a relational database, and the document queues use a relational database for data persistence. A small business edition is also available that does not require a database. The services that comprise the integration platform can be distributed across multiple physical machines. This feature allows for both the distribution of load as well as the ability to automatically recover from a hardware or

5 Page 5 of 18 network failure by provisioning the failed service(s) to a new machine. Once setup properly, there is no single point of failure in the architecture. This means that no single component of the architecture is assumed available on a specific machine within the network. Inherent with this design is the ability to assure server uptime based on available physical resources. The Boomi Integration Platform provides built-in features for failover and load-balancing. External components such as a J2EE application server or specialized file management system are not needed. The only external software application required is a relational database, such as Oracle, Microsoft SQL Server, or DB2. The database is mandatory for the storage of integration settings and document data. Fault Tolerance The logical services that comprise the Booi Integration Platform can be distributed across multiple physical machines to ensure continuous availability of the integration infrastructure. In doing this, central services to the platform are run in a redundant manner. Core services provide discovery and provisioning capabilities that are the heart of the failover scheme. As services connect to each other, such as when the queue services invoke a process service to execute one or more documents, the platform facilitates the link between these services. If a service is discovered as offline, the platform identifies another suitable node in the cluster that can handle this service and automatically provisions a new instance of the service. The process is then executed as normal, with minimal downtime and no loss of data. Load Balancing Certain services, such as the process service which is responsible for data transformation, routing and messaging, can be redundantly deployed across multiple nodes in the cluster. The advantage to this strategy is that other services that invoke this process (such as the queue service) will automatically distribute the work across all of the available process instances that are available. Data Persistence The queue service is exclusively responsible for preventing data loss. This is done by persisting data received into a relational database. This database is also used to store tracked fields associated with a document and all integration settings. In order to support availability of the data through persistence, Boomi recommends enabling failover or replication services on the application database used by the Boomi Integration Platform. Platform Configuration The desired adapter modules are chosen and can be plugged into the Boomi Integration Platform, providing an organization with exactly the right pieces required. Adapters can always be added at a later time as well. Adapters include document standards support, transports and business adapters. They will be covered later in this paper.

6 Page 6 of 18 Zero-Install Client The client applications use Java Web Start technology for deployment and updates. This provides users with all of the benefits of a Web-based application mainly no client installation or maintenance without the functional limitations imposed by a Web browser. Product Maintenance Boomi Software has gone to great lengths to ensure all products are distributed and updated quickly and easily. At the user's discretion, a product updater application can be run that will analyze the current version and download from a central server any patches or versions. Additionally, if a new component is purchased, simply running the updater will automatically download and install that component. Integration Platform Components Process Designer The Boomi Integration Platform provides a comprehensive set of components used to build an integration process model. By analyzing common integration patterns, Boomi offers a visual modeler to diagram the flow and execution of an integration process, utilizing the appropriate functional components based on requirements. The following section provides an introduction to the primary types of components available in the Integration Process Designer (IP Designer): Data Transformation. Executes a transformation of data from one format to another. The transformation is handled by defining two data profiles which describe the layouts of the source and destination fields. These profiles are used in a data map where the user can identify which fields in the source profile should map to which fields in the destination. Documents can be transformed between the following formats: XML Flat Files X12 EDI EDIFACT User-defined File Formats SQL Additionally, field level transformations are made possible through a user-customizable library of functions designed to handle many common field level transformations. These transforms included character appending/pre-pending/trimming, date mask manipulations, decimal precision, table lookups and many more. Transformations are built and maintained via a visual drag and drop style interface, allowing the designer to create and maintain maps in a natural, intuitive style. Queue Execution. Provides delivery of a document to a Boomi queue for persistence and execution on one or more adapters.

7 Page 7 of 18 Transport Adapter Call. Performs a direct invocation of a transport to send or retrieve data. Transports are typically the implementation of an Internet-based or network protocol. Examples include FTP, HTTP, SMTP, JMS, etc. Application Adapter Call. Performs a direct invocation of an application adapter to send or retrieve data. Adapters allow for application server level calls. A common term for this functionality is RFC, or remote function call. Examples of these types of adapters include SAP, PeopleSoft, JD Edwards, Oracle, database, etc. Process Call. Performs an invocation of another Integration process designed in the integration platform. This allows for the chaining of processes together and additionally provides for the reuse of processes that handle a common type of integration requirement. Program Command. Allows the execution of external programs made directly by the Boomi Integration Platform. The inputs to the external program are dynamically generated based on one or more fields within the data document itself. Additionally, a Java object may be invoked, allowing the document to be passed to the Java object for manipulation or processing. The Java object may return one or more documents to be passed to the next step of execution. Document Properties. As a document moves through the integration process, it will have properties associated with it that describe things like how it was received, the original file name, the host of the FTP server where the document was obtained and other natively supported properties. These properties may be inspected and overridden to allow for dynamic events to occur. For example, the name of the file created by the integration platform may be set based on a field or fields within the document itself, based on the current date, or based on a unique number. Other properties may be set as well, such as the from or to address that is used for ing the document, the subject of the message, the remote directory to write the file to on an FTP Server, and many other supported fields. Document Splitting. Files read into the Boomi Integration Platform may be in batch format, meaning the physical file contains one or more actual documents. For example, an Item master file may contain 1000 rows, and each row in the file represents one item. In certain circumstances, the file may need splitting into logical components or documents for processing. This can also include a header/detail type file that contains purchase orders or insurance claims. These documents are split up and processed as individual units through the process model. Message. The Boomi Integration Platform provides the ability to create notification messages that have dynamic content. For example, a message may need to be created when a purchase order is received with specific attributes. The message shape can be used to define this message, and the execution time of the message s content can be built dynamically based on content within the file itself. The message can then be delivered to the appropriate parties using the appropriate transport. Branch. Allows for a document to be passed down two or more paths in the order specified. This can allow a sequencing of steps in the integration process, such as document validation down step 1, and document processing down step 2.

8 Page 8 of 18 Merge. Reconnects multiple paths of execution for the purpose of synchronizing the process execution. Route. Provides content-based routing of documents in a process. Documents can be routed based on a field or fields in a file, by the queue that the document was originally received, by the ID of the sending or receiving partner, the application type, the transport type and more. Documents that are checked which do not match any of the defined values are sent down the default path for exception handling. Decision. Provides true/false validation by examining and comparing one or more fields in the document. Fields of data can be extracted from a document and used as part of a SQL call to determine if a record already exists. Additionally, comparisons are done using both simple operators like equal, not-equal, greater than, less than, as well as more complex comparisons, such as regular expression matching. Documents are passed down a true or false path based on the result of the comparison. Decisions may be chained together to facilitate more complex requirements. End Execution. Ends a particular path of execution, or the entire process execution for a given document. The end is a non-error termination. Exception. Provides dynamic exception handling. A field or fields within the document may be retrieved for use in the exception message. This will halt the execution of this document in an error status and log the message to the integration process logging mechanism. Users that are subscribed to receive alerts can be ed this exception message. Report Invocation. Powerful PDF or Excel document generation capability. Turn enterprise data from any source into a PDF or Excel document. By providing report invocation directly within the IP Designer, the report can be invoked as part of the actual integration process. For example, users can setup the platform to automatically generate a PDF of an invoice as EDI 810 invoices are received, and deliver that invoice via SMTP to a mail list. A powerful report designer is also available to layout a report. This designer allows the user to match current paper documents or standard document layouts, or create a customized format. Document Queues Document queues are an integral part of the Boomi Integration Platform by providing the safeguard and traceability of the data processed by Boomi. Document queues are ultimately responsible for sending and receiving data between adapters and processes within the platform. When errors occur, the queues provides automatic and manual retry of data. The primary features of document queues include: Data Persistence. All data processed by the Boomi Integration Platform is persisting at least once to prevent data loss. This allows for very durable recovery capabilities. Data Management. Data persisted on a queue may be viewed, modified (if permissions are set), removed, searched and re-processed. Data is archived off the queue at a user-specified period of time. Users specify which fields they desire to track on the queue, these user-defined fields may then also be searched.

9 Page 9 of 18 Automation. The queues are scheduled with one or more schedules to automate their execution. Additionally, they may be invoked through an event-based call by an external program. Data Retries. The queues track all data to a completion status. The user may configure automatic retry schedules to handle the retry of data in event of processing errors. Users may also selectively choose to manually reprocess a document at any step in the process via the IP manager user interface. Business Document Framework The business document framework provides the foundation for seamless document standard support. Document standards may be added easily to the Boomi Integration Platform, and those standards can then be understood and processed with minimal setup required. Support for multiple document standards is a requirement for many organizations because the needs from one trading partner to the next can vary significantly. Common features of Business Document Adapters: Pre-loaded Document Library. When possible, the document libraries for a particular document standard are installed by the framework. This simplifies the setup of specific documents that must be processed by automatically populating the data profile that describes the document. This avoids having to manually input the setup information. Library layouts may also be overridden, as many document standards will vary from business to business, requiring tailoring for each of your trading partners. Trading Partner Management. For business-to-business document standards, trading partners may be defined that correspond to the sender and receiver of a particular document. Specific rules for how documents should be processed can then be managed per partner. Documents are tracked by partner as well so they are easily found. Validation and Acknowledgment Handling. When applicable, the framework automates the handling of acknowledgment messages that confirm to the rules of the corresponding standard. Document queues indicate the status of a document as acknowledged and whether the acknowledgment indicates acceptance or rejection. Document Packaging and Unpackaging. Documents with rules as to how they should be packaged for transmission and/or unpackaged for processing are converted into the compliant structure automatically. Control Record Management. Control records exist in many document standards that identify values like transmission date, sender and receiver of the document, type of documents sent, a version indicator and others. This information is associated with trading partners and then referenced as needed to create standard compliant documents. Document Splitting Options. Standard-specific options for splitting up large batch files are provided. This provides flexibility for establishing how a batch of documents are processed such as all together, one at a time, or grouped into batches of a specified size.

10 Page 10 of 18 Error handling and Document management. Errors raised during document processing are displayed in the IP Manager interface. Failing documents are manually or automatically retried based on user preferences. Fields contained within the documents are tracked by the queue for debugging or tracing purposes. Those fields are searched from the IP manager interface. Automatic Alerts. Errors that occur during document processing may be ed to one or more interested parties. Examples of document standards offered by Boomi include X12, EDIFACT, HIPAA X12, SAP IDOC and RosettaNet. Business Adapter Framework Adapters provide the Boomi Integration Platform with connectivity to external data sources. An adapter is used anywhere in the integration platform where external data is to be retrieved or sent. It is assigned to and invoked by a document queue, preventing data loss and simplifying recovery. The adapters work by converting data to and from the application s native format into a standard format such as XML where it can be processed by the Boomi Integration Platform. Adapters are offered as separate components that are installed into the Boomi Integration Platform when needed. Common features of Business Adapters: Real-time and batch-based invocations. If supported by the external application, the adapter is configured to receive documents from the application in an event-based manner. Additionally, the adapter instance is invoked via one or more schedules defined by the user. Meta-data browsing. Adapters include a design-time feature that allows the user to connect directly to the data source to discover what interfaces are made available by that interface. The information about this interface is then used to automate setup in the Boomi Integration Platform. This greatly reduces the time spent on designing interfaces, and ensures an error-free setup. Application-tier access. A direct connection is made to the data source. This is typically the application server itself. For example, if using the SAP adapter, a BAPI is directly invoked on the SAP application server. Transactional execution. If supported by the data source, the user can configure the desired commit levels, and the adapter will manage transactions automatically. Error handling and document management. Errors raised by an adapter display in the IP manager interface. Failed documents are manually or automatically retried based on user preferences. Fields contained within the documents are tracked by the queue invoking the adapter(s) for debugging or tracking purposes. Those fields are searched from the IP manager interface as well. Automatic Alerts. Errors that occur during an adapter execution are configured to to one or more interested parties. Adapter API. Adapters are easily added to the Boomi Integration Platform by implementing a series of API s provided by Boomi. This enables Boomi to quickly and frequently offer our customers a growing

11 Page 11 of 18 list of options to help solve their integration challenges. Examples of business adapters offered by Boomi include SSA Global, SAP, PeopleSoft, JD Edwards, Oracle, Siebel, database and Web services. Database Integration The database adapter enables integration with any relational database that supports the JDBC standard. In addition to the features mentioned above for the other business adapters, the database adapter has advanced splitting and batching capabilities to ensure that integration processes will scale as the data load increases. SQL statements can also be grouped together transactionally to ensure data is written to the database correctly. Database connections can be pooled to maximize efficient usage and boost performance and scalability when connecting to the database. The user can specify a pool size, how long connections should be kept open, and how to verify connections are still viable. Transport Adapter Framework Transports are adapters that implement Internet or network-based standards to provide for the exchange of documents. They range from simple standards such as Disk or FTP, to the more complex such as the certified AS2 transport. Like business adapters, transports are invoked whenever data is sent or retrieved. If persistence of that data is required the transport may be assigned to a document queue. Common features of Transports Real-time and Batch-based Invocations. Many of the transports offered by Boomi may be configured to receive documents in both an event-based manner as well as batch-based. If batch-based, the transport instance is invoked based on schedules defined by the user. Field Tracking. Relevant transport-specific fields are automatically tracked in the IP manager where they may be viewed and searched. Acknowledgment Handling. If part of the standard, the transport will automatically generate and process acknowledgments. For example, the AS2 transport will automatically return an MDN (message delivery notification) to the sending partner if requested. The acknowledgment status of all documents processed by a particular transport is made available in the IP manager interface. Document Properties. Transport-specific properties are associated with the document(s) retrieved by that transport. For example, the file name of the document is retrieved. These properties are then used in the integration process to provide capabilities such as routing, dynamic messaging, decision validation and others. Load Balancing. Many of the transports may be load balanced to handle additional document throughput requirements. Failover. All transports are managed by the Boomi Integration Platform. If a cluster is configured by the integration platform administrator, then service failures are detected and that service is

12 Page 12 of 18 automatically re-provisioned onto another available node in the cluster. Automatic Alerts. Errors that occur during an adapter execution are ed to one or more interested parties as configured. Transport API. Transports are easily added to the Boomi Integration Platform by implementing a series of API s provided by Boomi. This enables Boomi to offer our customers a growing list of options to help solve their integration challenges. Examples of transport adapters offered by Boomi include HTTP(S), FTP(S), WebSphereMQ, MSMQ, Oracle AQ, DISK, POP/SMTP, AS1 (Certified), AS2 (Certified) and AS3 (Certified). Using the Boomi Integration Platform The Boomi Integration Platform is setup and managed using two main interfaces: IP designer and IP manager. The following section briefly covers how to design and test integration processes. This section also describes how to monitor processes which are running in an automated manner. IP Designer: Building Integration Processes The IP designer interface includes all components available to the integration platform and allows the user to create integration processes by sequencing these components together using a visual modeler (Illustration 1). The user creates the process by clicking on the desired component on the left portion of the interface and dragging the component onto the process canvas. Outbound lines are connected from one shape to the next by selecting and dragging the line to its intended shape. The graphical designer provides the user with a high-level view of the entire integration process. To expand the detail of the process, the various shapes may be opened to view its specific settings and properties. These processes may be exported from one environment and imported into another, making deployment from a test environment to a production environment possible.

13 Page 13 of 18 Illustration 1 Boomi Integration Platform: Designer Application Integration Projects All components in the IP designer are organized into projects. This enables teams to collaborate in the development of integration processes while protecting sensitive setup details from being modified. Projects can be shared amongst each other, enabling users to provide a library of components that can be shared by users across multiple projects as needed. Administrators maintain access lists to projects. Components that are shared across projects are referenced in a read-only manner preventing another user from accidentally changing a component in use by another process. Users only see the components in the projects to which they have access. Users are defined and managed in the Boomi Integration Platform or queried via an LDAP source to promote single sign-on for the enterprise. Users are also protected from accidentally modifying a particular component simultaneously. If a user attempts to modify a component in use by another user, that user will be notified and preventing from making changes until that component is available.

14 Page 14 of 18 Explicit Error Handling Beyond the standard error handling available in the Boomi Integration Platform, the user has the option to enable explicit error handling at the component level. When enabled, an additional line will appear on the shape where this feature is activated entitled error. At runtime, if errors occur, that document is passed down this error line and the process continues executing. The user has the flexibility to capture the error and handle that document when the error occurs as needed. IP Manager: Monitoring and Administration The IP manager interface is a separate interface that enables the execution, monitoring, error handling and administration of integration processes required for the Boomi Integration Platform. A few of the specific areas handled by the IP manager interface include: Current Activity. Monitor which integration processes are currently executing, as well as upcoming scheduled executions and any recent errors. Queue Management. Inbound and outbound queues are displayed listing recent documents processed. From here the user has options to view the data, search documents, view logs, manually execute a queue, retry a queue to re-process error documents, and more. Enterprise Reporting. View reports from within the IP manager interface, or any Web browser. Reports can be customized as needed beyond the standard library of reports offered. Alert Management. Configure which processes the user is interested in monitoring. Upon failure of subscribed processes, users are ed error notification reports. Project and User Management. For Boomi administrators, the project access lists are defined and managed here. Digital Certificate Management. Create, import, export and remove digital certificates for security standards such as SSL, AS1, AS2 and others. The Complete Integration Process The Boomi Integration Platform combines all of the components necessary to complete an integration process. The following section demonstrates how these components work in concert to achieve a complete integration process. To better understand how the integration platform is set up to implement these processes, it is important to understand the sequencing of steps which occur in each of the primary integration process components. Step-by-Step Sequence 1. Inbound Queue Execution. An inbound queue is the initiator of any integration process. It is invoked through one of the following methods:

15 Page 15 of 18 a. Event-based. Certain adapters that support event-based receipt of data deliver documents to queues in real-time. Examples of event-based adapters include the HTTP transport, AS2 transport, SAP application adapter, WebSphereMQ transport, and many others. Additionally, queues can be executed by implementing a Java API included with the platform. b. Batch-based. Queues are scheduled to execute by creating and starting one or more schedules that reflect the desired execution times. The schedule service then invokes the appropriate queue based on these settings. The role of the inbound queue is to ensure the data is safely persisted to prevent data loss. Additionally, the inbound queue tracks the data it receives until it is successfully processed by the linked integration process(es). Failed documents are retried automatically by the inbound queue, minimizing the need for human intervention. 2. Adapter Invocation. Adapters are responsible for receiving data from the appropriate source parties in the appropriate format or through the appropriate protocol(s). For inbound processes, one or more adapters are associated with an inbound queue. This association links the specific adapter instance with the queue instance responsible for persisting that data. The way in which the adapter communicates varies depending on whether process is event based or batch based. a. Event-based. The adapter is listening for the receipt of incoming data. When data is received, these adapters connect to their corresponding queue instance and deliver the data for persistence and processing. b. Batch-based. The schedule service executes the queue based on predefined schedules. The queue then executes each adapter assigned to it in turn instructing the adapter to check for new data based on that adapter s pre-defined settings. 3. Integration Process Execution. An integration process is linked to one or more inbound queues. Multiple inbound queues may also deliver data to the same integration process. In either case, the integration process coordinates the flow of the documents passed to it from inbound queue to outbound queue. Within the process is a series of steps (represented visually to the user) that encompasses the implementation of integration requirements for a particular interface. This may include: the transformation of the data from one format to another; validation of the data; routing of the data based on user-defined conditions; exception handling; messaging; and more. The result of the integration process is typically the delivery of the data in its final form to the appropriate outbound queue to prepare it for delivery to the destination party or application. 4. Outbound Queue Execution. Outbound queues are essentially the reverse of the inbound queues. They are responsible for persisting the data passed to them via the integration process. Upon persistence, the outbound queue invokes the associated adapter to deliver the data to its final destination. The outbound queue tracks the success of each adapter invoked and will retry failures based on a user-defined schedule. This follows the consistent design objective to minimize human intervention. 5. Adapter Invocation. Always the final step in the interface, the adapter is responsible for delivering

16 Page 16 of 18 data through a specified protocol and/or format to a final destination. The destination may be an enterprise application, a directory, an FTP server, or something else. The adapter must report the result of the process of sending the data back to the calling component (normally an qutbound queue) in order to successfully complete the interface. Example: Inbound Shipment Order The following example covers how the Boomi Integration Platform is utilized to handle the receipt and processing of shipment order documents. A warehouse is required to receive shipment orders from all of their customers in the required format and using the delivery method required by that customer. This particular example covers receiving an X12 EDI formatted shipment order over AS2 for one particular customer. After receipt, the shipment order is sent to a WMS (warehouse management system) and a custom Web portal. Adapter Invocation - An AS2 transport is created that listens for incoming documents with the AS2 identifier which matches the customers AS2 identifier. Documents received by this transport are delivered to a document queue created to store all incoming EDI documents for this particular customer. Inbound Queue - Because the data is X12 EDI, the queue has the X12 document standard assigned to it and will automatically handle validating the EDI data and breaking it up from its batch format into individual shipment orders. A functional acknowledgment is returned to the originating partner indicating successful receipt of the data. Integration Process - After the documents are processed and safely stored on the queue, they are passed on to an integration process built to handle this customer s incoming EDI data. Decision - The integration process first extracts the shipment order number out of the document and references it against an internal database to determine if this document is already received. If it has, a document is created and ed to an internal analyst indicating that a duplicate order is received. The document is then rejected. Data Transformation - The shipment order document is transformed from its X12 EDI format into an XML format that is required by one of the receiving applications. Application Adapter Call - This new XML document is passed to an adapter. The Adapter takes the XML document, converts it to the native destination application format, and delivers it to the WMS application. Data Transformation - Because this shipment order document is also sent to a Web portal application, it is also transformed into a series of SQL statements. Application Adapter Call - Finally, it is passed to a database adapter where it is written to the database of the Web portal. Note that this example covered a X12 EDI shipment order. However, a very similar process is simply setup to handle flat file data, XML data, or whatever format of the shipment order is required.

17 Page 17 of 18 Example: Customer Data Synchronization The following example covers how the Boomi Integration Platform is used to handle the synchronization of customer data between two internal applications. An ERP application and a CRM application require synchronization. When a customer record is added or modified in the ERP application, it is reflected in the CRM system by adding or modifying the corresponding record. The ERP publishes this type of information in its native format, but has no capabilities to format or move the information outside of its own application. Adapter Invocation - A business adapter is created that listens for incoming customer documents. The adapter notifies the ERP that it is interested in these types of documents. Documents received by this adapter are converted from the native format of the ERP into XML. Inbound Queue - The adapter then delivers this document to a document queue created to store all incoming documents for this ERP application. Integration Process - After the documents are processed and safely stored on the queue, they are passed on to an integration process built to handle the synchronization of customer data. Decision - The integration process starts with a decision that extracts the customer ID key out of the document and references this against the CRM database. This step determines if this is a new customer record or an update. If new, the customer does not yet exist in the CRM. An update indicates the customer record does exist in the CRM and therefore the record is updated. Data Transformation - Based on the result of this Decision the document data is transformed into an insert customer record or an update customer record complying to the format required by the CRM. Outbound Queue The data is then delivered to an outbound document queue for guaranteed message delivery. Transport Adapter Invocation - Because the CRM application has an HTTP-based interface, an HTTP transport is created to connect to the CRM s HTTP server using an SSL connection for greater security. Conclusion Integration processes benefit organizations in various ways. The Boomi Integration Platform provides significant cost savings to organizations by reducing data-entry errors, improving supply chain responsiveness, increasing inventory accuracy, decreasing order fulfillment times, reducing or eliminating document processing fees and customer charge-backs, and many other reasons. The Boomi Integration Platform is especially important when initiatives arise that are out of the organization s control. For example, Wal-Mart and numerous other retailers have mandated AS2 as their document

18 Page 18 of 18 communication standard. This standardization initiative forces their network of 16,000+ suppliers to adopt and implement an AS2 certified solution. HIPAA compliance, Sarbanes-Oxley, and EPC/RFID are further examples of industry standards that are mandated by government groups or industry giants. These mandates have strong implications in business integration. The value of a product such as the Boomi Integration Platform in the marketplace is the adaptability gained in order to meet changing business requirements. The goal of this document is to provide the reader with a base of understanding of the Boomi Integration Platform capabilities, its high level features and functions, and its architecture. Please contact a Boomi sales representative for more information at , or sales@boomi.com. About Boomi Software Boomi Software improves the efficiency and effectiveness of mid-size businesses by connecting disparate applications and legacy data. The company delivers every type of integration a mid-market business needs in one easy-to-deploy, simple-to-use product. Boomi s integration projects are up and running in weeks, not months, and do not require a large development staff. Backed by its extraordinary support services, customers quickly see the benefit of their investment in Boomi. For more information about Boomi Software, visit or call