Application Route (for Application-to-Application Routing)

Application Routes are a means of associating a business document with a process that transforms the document into a format expected by you or a trading partner.

Business documents that are traded between you and your trading partners typically adhere to format/style that you both have agreed to. The format of business data in your internal applications is typically different than the format of the data you send to your trading partners. Sending your business documents to your trading partners requires a process that transforms the data from your internal application format into the format expected by your trading partners. Application Routes allow you to associate a business document in your application-specific format with the process that transforms it into the format expected by your trading partners.

Business Use Case

Suppose you need to send invoices to your trading partners. You may send out all your invoices in a daily batch, or individually as the order has been fulfilled. Either way, you need a way of identifying an invoice in your internal application with a process that turns the invoice into the format agreed upon by you and your trading partners. Invoices in your internal application may be a collection of related database tables, an XML or Flat File document, etc. Your trading partner may be expecting you to send the invoices in a different flat file or XML format. Therefore, a process of turning the database, flat file, XML, or Spreadsheet data into a different flat file or XML document is required. Application Routes are used in conjunction with other processes that retrieve the invoices in your internal application format. These "other" processes know how to carve up a batch of invoice data into single invoice documents. Once the "other" process has identified a single invoice, Application Routes are used to find the correct process that transforms it into the flat file or XML document your trading partner expects.

Application Routes are different from Outbound EDI Routes. Application Routes are used to transform your application data into non-X12 and non-EDIFACT formats (i.e. XML, proprietary delimited & fixed-length flat file). Outbound EDI Routes are used to transform your application data into X12 and EDIFACT formats.

Note: Application Routes do not "do" anything. They simply provide a way for other runtime processes to "find" or "locate" the process that will transform your application data into the correct external format.

Typically, you will be sending invoices to more than one trading partner. Additionally, each trading partner may have their own expectations/requirements for the document format. All may want the same flat file format, but they may differ in the records and fields they use/expect. In this case, you will have multiple Application Routes - one for each trading partner. The processes that carve up your internal invoice format into individual documents can also identify to whom the invoice is to be sent. Once the process isolates a single invoice and knows to whom it should be sent, Application Routes are used to find the process that transforms the invoice into the format required for each trading partner.

Additionally, a business may trade Invoices and Advanced Ship Notices with a single trading partner. The information for both business documents is most likely stored in the same internal application, although the data for each document probably comes from different DB tables or a different flat-file format. The key field information (i.e. "Customer_Number", "Vendor_ID", etc.) in the application is usually the same regardless if you are sending Invoices or Ship Notices. Creating a hierarchy of Application Routes provides you with the ability to organize and more easily handle situations when to key information changes in your application. In this example, you could create an Application Route that specifies the "Customer_Number" key value as the top Application Route in the Hierarchy. Following that, you could create two "child" Application Routes, with the "Customer_Number" Route as the parent. The "child" Application Routes, will inherit the "Customer_Number" value, but additionally specify "Document_Type" values - Invoices and Ship Notices. In the end, you wind up with 3 Application Routes. If you ever need to modify the "Customer_Number" value for this example, you can change it in the parent Application Route. Since the "child" Application Routes inherit this value, they are automatically updated. Taking this example even further, if you trade 8 or 10 different document types with a Trading Partner, it becomes even more convenient to change a single Application Route, but distribute that change to all "child" Application Routes.

The CIC Studio provides the ability to re-use Business Processes across multiple Application Routes. This enables you to build a common Business Process (which are usually static), but dynamically provide runtime values that match the details of the Route. For example, the Business Process may simply perform a Ruleset activity and finish. This process or functionality may be the same for all your Trading Partners/Route/Documents. However, what changes for each Trading Partner/Route/Document is the Ruleset that transforms the business document into a format expected by your trading partner; the process is the same, but the details of the Ruleset are different. Studio allows you to build the Business Process one time, re-use it, but dynamically pass the Ruleset that is used by the Business Process for transformation. In this case, a properly constructed Business Process (adheres to the Application Route Template, and specifies a Ruleset parameter), can be attached to the Application Route.

How the Object Works

Application Routes create an association between key fields in your application data and a Business Process. Application Routes are used in conjunction with a Data Analysis Ruleset. Rulesets that analyze application data call specific actions that search the Application Routes. Application Routes are searched according to the key fields in an Application Interface. An Application Route is "found" by the action, when the data supplied to the action by the Data Analysis Ruleset matches the data configured in an Application Route.

For example, the key piece of data in your invoice application may be "Customer Number". "Customer Number" may be enough information for you to distinguish between Invoices that are sent to ABC Customer and XYZ Customer. When the Data Analysis Ruleset is processing a batch of invoices, it will use the "Customer Number" (for a given Invoice) to search the Application Routes. If you have an Application Route that has been configured with a "Customer Number" value matching your application data, the Application Route will be found by the Analysis Ruleset.

Note: Application Routes commonly have more than just a "Customer Number" identifier. They will also commonly have a "Document Type" value. For example, you will commonly have Application Routes associated with Invoices and Application Routes associated with Shipment Notices. In order to direct the Studio to execute different processes for Invoices and ShipNotices, you will have to configure additional information into the Application Route. Use of a "Document Type" attribute in addition to "Customer Number" will enable this capability.

As a final step in the "search" action, when an Application Route is "found", the action retrieves the associated Application Route Business Process from the Application Route and executes it.

Process Summary

To use this object, you must:

• Create and Define the object.
• Create and Define an Analysis Ruleset.
• Create and Define Business Processes and related objects that process application data.