Sign in

Using CCP Resources to display EDI Data in the CIC Cockpit

  • Updated

This article describes how to configure your existing integration Projects with the CCP resources (Projects and attributes included in the default EDI Document Types) so that you can see your EDI data displayed in several CIC Cockpit pages.

This article does not describe how to populate non-EDI data in the Cockpit.

Prerequisites

Please read, understand, and complete any required setup steps as described in the articles below before starting to use the CCP resources to populate the CIC Cockpit.  

Overview

There are three related objects you that are common to your inbound or outbound EDI integration Projects - and it will be these objects that we configure to include references to the CCP resources. They are:

  • Business Processes
  • Routes
  • Rulesets

A typical EDI Pattern is shown below. Let's start with the resources for inbound integration Projects.

  • The Inbound EDI Business Process (BP) is the main BP that executes your total inbound EDI integration. (Hint: this is the one created using the Inbound EDI Business Process template)
  • The Inbound EDI Route that activates that Business Process.
  • The Ruleset that will be used to perform the data transformation within your integration Project.

This diagram shows a common pattern used for inbound EDI, in which an inbound Purchase Order (850) will be transformed to a Flat File format. Note that these objects may exist in the same Project, or more likely,  across multiple Projects (Core, Trading Partner, etc). For the purpose of this article, we will assume all objects are within a single Project. We will also reference these generic names (Inbound EDI Business Process, for example).

mceclip1.png

Instructions for your Inbound Projects

Take these steps to edit your Inbound EDI Business Process, Inbound EDI Route, and Ruleset.

Edit the Inbound EDI Business Process 

The CCP contains Business Processes and Rulesets that expect certain values to be passed to them from the Inbound (and Outbound) Business Processes that you have created as part of your integration Projects. You will manually add these values to your Inbound EDI Business Processes. 

You will also edit your Inbound Business Process to include a reference to the inboundCockpitReferenceBPS Business Process, which can be found in the cleo.com.cic.cockpit.core Project (Inbound Package). This pre-defined Business Process will help populate the CIC Cockpit pages with user-defined information indicated by field values and other values. 

You will also edit your Inbound Business EDI Business Process to call the inboundErrorCockpitBPS to notify you when errors exist in your transformation.

Steps

  1. From the Project Explorer, open the Inbound EDI Business Process using the Business Process editor.
  2. Add several required Fields to the Business Process.  Fields can represent a value, such as a string, but they can also represent an object, such as a Ruleset or Transformation Settings. The object supplying the value would be a corresponding Route for EDI or Application templates or an EDI enveloper for Connection Business Processes. 
    From the Fields section of the editor, add these fields:
    • f_partnerName       (type = String)
    • f_docType               (type = String)
    • f_cockpitRuleset     (type = Ruleset)

    Notes:

    • Based on recommended naming conventions, each field name has "f_" in front of it, to indicate it is a field.  Similar naming conventions include "v_" for variables and "p_" for parameters.
    • For each item in the list above, all Types should be set to string, with the exception of f_cockpitRuleset, which should be set to Ruleset.
  3. Now add the inboundCockpitReferenceBPS task to the Script section of the editor. Place this after the Execute Transformation - Single output task.
  4. Define the properties for this task using fields and variables:

  5. Add the inboundErrorCockpitBPS. This BP will notify you if errors exist in your transformation. Place this after the Set Exist Status task.

  6. Define the Properties for this task:

    mceclip2.png

  7. Provide a Label for the inboundErrorCockpitBPS task, and then change the Fail value for the Execute Transformation – Single Output task to that same label. Failure is used here.

    mceclip0.png

  8. Select the inboundErrorCockpitBPS task and add the Set Exit Status task.

  9.  In the Properties tab on the bottom of the page, provide a value for the Set Exit Status task's single parameter as follows:

  10. Save and close the editor.

Edit the Inbound EDI Route  

The Inbound EDI Route (specific to your Trading Partner and the document type) must now be edited to provide appropriate values for the new fields that were created above in the Inbound EDI Business Process.

  1. Open your Inbound EDI Route from the Project Explorer. The EDI Route editor appears. 

    mceclip6.png

  2. In the Process Binding area, double-click the name of the Inbound EDI Business Process you're using. 

    mceclip0.png

    The Properties tab appears, with the fields that you added to the Business Process.
  3. Enter values for each of the fields as shown below:
    Field name Value
    f_docType <the EDI document type> For example, 850.
    f_partnerName <your partner name>
    f_cockpitRuleset This is the Ruleset that will be used to actually move the transformed data into the CIC Cockpit. This object resides in one of the EDI document-specific Projects that you'll download as part of the CCP.

    Note: This is not the Ruleset used to actually transform data as part of your Trading Partner-specific integration Project.

    For example: 

    com.cleo.customer.core.cockpit.n850.inbound.inbound850v4010CockpitRS

Ruleset

The Ruleset (specific to your Trading Partner and the document type) must be edited to map elements of the source EDI document to the proper variables in the env category of the Variables panel. In this example, the Ruleset is transforming a Purchase Order (850), and we will map the element for the PO number - BEG03 - to a User Reference field. The purpose of these fields is to pass data from the CCP to the Cleo Integration Server so that data can make its way to the Cockpit. 

Note: For other transformation types, the element will reflect the actual document type you're using. 

mceclip0.png

  1. Open the Ruleset using its editor. mceclip0.png
  2. From the Rules area, create a new Move rule under the proper Composite Rule (use the New Simple Rule icon). The location must respect the organizational hierarchy of the Schema, so the element you grab (and thus the rule you create) must be a child of the proper composite; however where exactly under that composite does not matter. In the example above, we will add the rule under the existing rule #5.

    The new Move rule is added below the one you selected. 

    mceclip0.png

  3. With the new rule selected, navigate from the source schema to BEG 03: Purchase Order Number (324) as shown below.

    mceclip0.png

  4. Add a source node to the rule by clicking and dragging the BEG03: Purchase Order Number (324) item into the Value column in the Properties tab.

    mceclip0.png

    The source node is added. 

    mceclip0.png

  5. Add a target for the Move rule. In this case, it will be a variable. 

    On the right side of the page, click the Variables tab, and click the env node. 

    mceclip0.png

  6. From the expanded env node, drag User_Reference_1 to the Return Assignments table in the Properties tab. 

    Note: There are five User Reference fields available from the ENV folder in the Variables panel of the Ruleset editor. These can be used to add custom fields to your Ruleset. The purpose of these fields (for Cloud integrations) is to pass data from the CCP to the Cleo Integration Server so that data can make its way to the Cockpit.

    mceclip0.png

    It should look like this:

    mceclip0.png

  7. Save your work.  Notice that your new rule has been assigned a quick reference number. 

    mceclip0.png

Results

  • When the inboundCockpitReferenceBPS executes successfully, the inbound transaction details will be sent to the CIC Cockpit and made viewable in the grid and tiles there.
  • Should a failure in the Ruleset occur, then the inboundErrorCockpitBPS will execute and send the data to the CIC Cockpit along with transaction details. There then would be a ticket created in the CIC Cockpit with the status as 'New' for the message sent.

Instructions for your Outbound Projects

This is basically the same process as described in the instructions for inbound Projects; the difference being the objects being edited.

  • The Outbound EDI Business Process (BP) is the main BP that executes your total outbound EDI integration. (Hint: this is the one created using the Outbound EDI Business Process template)
  • The Outbound EDI Route that activates the Outbound EDI Business Process.
  • The Ruleset that will be used to perform the data transformation within your integration Project.

This diagram shows a common pattern used for outbound EDI, in which an inbound Flat File will be transformed to an EDI Invoice (810). Note that these objects may exist in the same Project, or more likely,  across multiple Projects (Core, Trading Partner, etc). For the purpose of this article, we will assume all objects are within a single Project.

mceclip0.png

Edit the Outbound EDI Business Process

The CCP contains Business Processes and Rulesets which expect certain values to be passed to them from the Outbound Business Processes that you have created as part of your integration Projects. We will manually add these values to our Business Processes. 

You will edit your Outbound Business Process to include a reference to the outboundCockpitReferenceBPS Business Process, which can be found in the cleo.com.cici.cockpit.core Project (Outbound Package).  This pre-defined Business Process will help populate the CIC Cockpit pages with user-defined information indicated by field values and other values. 

You will also edit your Outbound Business EDI Business Process to call the outboundErrorCockpitBPS to notify you when errors exist in your transformation.

Steps

  1. From the Project Explorer, open the Outbound Business Process.
  2. Add several required Fields to the Business Process.  Fields can represent a value, such as a string, but they can also represent an object, such as a Ruleset or Transformation Settings. The object supplying the value would be a corresponding Route for EDI or Application templates or an EDI enveloper for Connection Business Processes. 

    From the Fields section of the editor, add these five fields: 

    • f_cockpitRuleset
    • f_tpIdValue
    • f_partnerName
    • f_docType
    • f_reprocessParms

    Notes:

    • Based on recommended naming conventions, each field name has "f_" in front of it, to indicate it is a field.  Similar naming conventions include "v_" for variables and "p_" for parameters.
    • For each item in the list above, all Types should be set to string, with the exception of f_cockpitRuleset, which should be set to Ruleset. 
  3. Now add the outboundCockpitReferenceBPS task to the Script section of the editor.  Place this after the Execute Transformation - Single output task.
  4. Define the properties for this task using fields and variables:

    mceclip6.png

  5. Provide a Label for the outboundErrorCockpitBPS task, and then change the Fail value for the Execute Transformation – Single Output task to that same label.  Failure is used here.

    mceclip7.png

  6. Select the outboundErrorCockpitBPS task and add the Set Exit Status task.
  7. In the Properties tab on the bottom of the page, provide a value for the Set Exit Status task's single parameter as follows:

    mceclip0.png

  8. Save and close the editor.

Edit the Outbound EDI Route

The Outbound EDI Route (specific to your Trading Partner and the document type) must now be edited to provide appropriate values for the new fields that were created above in the Outbound EDI Business Process.

  1. Open your Inbound EDI Route from the Project Explorer. The EDI Route editor appears.
  2. In the Process Binding area, double-click the name of the Outbound EDI Business Process you're using and enter the values for each of the fields as shown below. These appear in the Fields tab of the Properties view.
Field name Value
f_partnerName The user-defined Trading Partner name.
f_doctype The EDI document type. For example, 810.
f_tpIdValue The EDI ISA Sender ID.
f_cockpitRuleset This is the Ruleset that will be used to actually move the transformed data into the CIC Cockpit. This object resides in one of the EDI document-specific Projects that you'll download as part of the CCP.  The actual Ruleset selected will be based on the document type, inbound or outbound direction, and Schema version.

Note: This is not the Ruleset used to actually transform data as part of your Trading Partner-specific integration Project.

For example: com.cleo.customer.core.cockpit.n810.inbound.inbound810v4010CockpitRS
f_reprocessParms These are values that will be passed to an outbound Route when reprocessing occurs. The first value (RouteValue01) is the Application Interface object that is being referenced. This a mandatory field. It can be followed by any other attribute values (RouteValue02, RouteValue04, etc) included in that Application Interface that you wish to include. The limit is 20. All values must be comma-separated.

For example:

<RouteValue01, RouteValue02>

MFDelimFlatFileAI,ACME

Ruleset 

The Ruleset (specific to your Trading Partner and the document type) must be edited to map elements of the target EDI document to the proper variables in the env category of the Variables panel. In this example, the Ruleset is transforming data to a Purchase Order (810), and we will map the element for the Invoice document identifier - BIG02 -  to a user reference field. In other transformation types, the element will reflect the actual document type you're using. BEG03 for a Purchase Order number, etc.

The basic steps to edit the Ruleset are explained above for the inbound scenario. Note that actual elements to be mapped must reflect your actual document type used in your integration. 

Results: 

  • When the outboundCockpitReferenceBPS executes successfully, the outbound transaction details will be sent to the CIC Cockpit and made viewable in the grid and tiles there.
  • Should a failure in the Ruleset occur, then the outboundErrorCockpitBPS will execute and send the data to the CIC Cockpit along with transaction details. There then would be a ticket created in the CIC Cockpit with the status as 'New' for the message sent.

Testing & Deploying Your Projects

All Projects in the above scenario must be deployed, including CCP.

Related Topics:

Promoting Projects (Integration Engine Deployment)

Related articles

Comments

0 comments

Please sign in to leave a comment.