There are several key concepts, functionality, and processes that you should explore and understand before you can effectively design your transformations in the CIC Studio.
- Projects, Packages, and Resources
- Cloud Adapters
- Business Processes and Routes
- Rulesets and Schemas
Projects, Packages, and Objects
The creation and planning of Projects, Packages, and Objects mark the starting point when you begin to use the CIC Studio. You'll begin by building these resources.
- A Project is the primary hierarchical level, or parent folder, used for organizing design-time objects. It is the deployable unit when publishing (promoting) to your remote Integration Engine in the cloud, and the shareable unit when collaborating with other team members via an SVN Repository. Projects and their resources are built and maintained in the Studio’s Workbench perspective. A Project must exist before any additional resources can be contained within.
- A Package is the secondary hierarchical level, or child folder, used for organizing objects. A Project can contain one or more Packages. For example, you can create different Packages according to their functionality, usability, or category. A common use is for the direction of the documents to be processed: inbound or outbound.
- An individual Object, or generally referred to as a resource, is located within one Package. An object is in only one place at one time. Code Tables, Rulesets, Business Processes, and EDI Envelopers are examples of objects that you create and configure in the Studio.
How you get the data into and out of the CIC is one of the first things you'll need to determine as you plan and build transformations. The Cloud Adapter facilitates connectivity with CIC data as part of transformation and is used to communicate payload traffic from the Studio to a location specified by a selected Endpoint.
Business Processes and Routes
The Business Process object performs tasks on data, in a user-defined sequence. It can activate all other objects. For example, it can: execute or launch other objects in your integrations, manipulate data (strings and arrays), move or route data based on content, analyze documents, import and export data.
It is the primary object to sequence and execute the necessary tasks for your transformation to occur.
To get started using this powerful object, please refer to Business Processes.
Routes are objects that identify, process and route your inbound and outbound data. Types of routes are dependent on whether your data is EDI (EDIFACT and X12) or non-EDI (XML, proprietary delimited & fixed-length flat file, JSON, spreadsheets, database, etc).
- Inbound EDI Routes associate an EDI document's "envelope" information with a corresponding Business Process. When an EDI document is received, the Studio will parse the EDI envelope segments, search the Inbound EDI Routes for one or more that match the envelope information, and then call all the Business Processes that are attached to the Inbound EDI Route.
- Outbound EDI Routes associate your ERP's document format with a business process that produces a business document your trading partner expects. When an ERP business document is received for outbound EDI processing, the Studio will group the data, search the Outbound EDI Routes for a match, and then call all the Business Processes that are attached to the Outbound EDI Route. The Business Process performs the activity of converting your ERP's business document into the business 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). Conversely, Outbound EDI Routes are used to transform your application data into X12 and EDIFACT formats).
- Inbound EDI Pipelines
- Outbound EDI Pipelines
- Application Route (for Application-to-Application Routing)
Rulesets and Schemas
The Ruleset object is a collection of rules that govern the way one business document is transformed into another. Put more simply, it's the tool that allows you to take square pegs (source data) and plug it into the round holes (target data). The syntax of the sources and targets may be the same or different. For example, it could be flat file-to-flat file or EDI-to-XML.
The CIC Studio's transformation engine relies on the rules in a Ruleset to transform or analyze documents. It uses the format defined in a Schema to create nodes that can be the source(s) or target(s) of each rule.
Each Rule is defined by an Action; the Actions can be one of the Cleo-supplied Actions, or Actions based on user-created objects.
You must create a Rule for each piece of data you want to appear in the target document.
A Schema is referenced in a Ruleset. When you are creating a Ruleset, you'll provide the source and target Schema types, and you specify the specific Schemas for each. Then you use the pieces of the blueprint (fields, cells, elements, etc.) in the Schemas as input and output for rules within the Ruleset.
The Schema object defines data. This includes metadata qualities like datatype, field length, decimal places, and EDI message ID. It also includes descriptions of fields, cells, or elements, such as order number, unit price, etc. The CIC integration engine uses the Schema object to determine how a document should be read or written. There are Schemas for each of the supported syntax categories: Database, EDI, Flat File, XML, JSON, Spreadsheet, including some that are specialized. See Schemas (Overview) for more information.
Deployment (generally referred to as Publishing in CIC terms) describes the act of making Projects and objects ready for testing or production-ready integration with your integration engine (cloud server).
Promotion occurs at the Project level, where Projects are bundled and then deployed in their entirety, with all dependencies between other Projects in working order (i.e. no errors).