A hierarchical organization of Projects, Packages, and objects lends itself to a modular approach for developing your transformation solutions in the Studio. This article introduces these fundamental components.
A Project is the primary hierarchical level, or parent folder, used for organizing design-time objects. It is the deployable unit when distributing solutions to the CIC Integration Engine (your cloud server), and the shareable unit when collaborating with other team members via an SVN Repository.
In this example, all resources (objects and other files) for your company’s transactions with one trading partner are all contained in ProjectA, while ProjectB houses all resources necessary for doing business with another trading partner.
Projects and their resources are built and maintained in the Studio’s Workbench perspective.
Projects can be placed in a version control system so they can be shared with other team members. Once you place a Project in version control, you can synchronize changes, resolve differences, keep track changes, and see project history.
For more information on version control, see Versioning & Synchronizing Projects.
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.
An individual object, or resource, is located within one Package. An object is in only one place at one time.
All resources for one trading partner can be easily found, deployed, modified, and re-deployed - if organized within a single Project. These resources are separate from other trading partners.
Despite being separate, a Project may reference a Package in another Project. Therefore, although an object only exists in one place, it can be used in multiple Projects.
In the above diagram, Package2 might contain a Schema used by a particular document type. If the Package that the Schema resides is made available to other Projects, other Projects that need to interact with that Schema can reference that single Schema.
Cleo recommends that a separate Project, called Core, be created for common resources. That Project should contain objects that can be used by multiple trading partners. If a Project is to make its resources available to other Projects, you must explicitly declare the Packages in the Project to be shared. To learn how to do this and other related tasks, see Sharing Resources.
Creating Core Projects
Cleo recommends that a separate Project, typically called Core, be created for common resources. That Project should contain objects that can be used by multiple integrations (i.e trading partners, etc).
Despite being separate, a Project may reference a Package from another Project. Even though an object may exist in one place, it can be used (referenced) elsewhere by other Projects.
Consider this example. You have 3 trading partner Projects - Acme, BigStore, and Comco. While each Project contains resources/objects specific to that trading partner, they all can use the same object - an EDI Schema for example. Your Core Project could contain the Schema while the other Projects reference it. You'll need to configure the Projects involved in this scenario.
- If the Package that the Schema resides is made available to other Projects, other Projects that need to interact with that Schema can reference that single Schema.
- If a Project is to make its resources available to other Projects, you must explicitly declare the Packages in the Project to be shared.
For detailed information on sharing, see:
Project Design Considerations
When it comes to designing Projects, always plan your approach before you get started. Ask yourself these questions:
How many do I need?
You might need more than one. Certainly at least one trading-partner-specific Project. But, how many "cores" is the real question.
What goes where?
There is no one-size-fits-all answer to this question. Certainly, the EDI objects should be in the EDI Project, and perhaps the A2A objects in their own Project. Be logical and organized when it comes to placing the objects.
Where do I start?
Start with the Core Project. Then, maneuver your way with the additional (if any) “cores” before attacking the trading-partner-specific Projects.
Projects (and other resources) can be created, managed, and organized from the Project Explorer view of the Workbench perspective.