> > > Best Practices – Project/Package Structure

Best Practices – Project/Package Structure

21st June 2016

Sean Hoppe Consulting Group

In our previous tips focusing on best practices in Cleo Clarify, we discussed why the Core Project and the Base Project should be included in your implementation and design.  Once you have both Projects created, you’re ready to start creating Trading Partner-based resources.  You may know all about Rulesets, Business Processes, and Schemas.  But, do you know where they should go in your Project Explorer?

This tip, we’ll focus on your Trading Partner Projects, which should contain Trading Partner-specific resources and objects.  We’ll walk through how to organize those objects, and discuss when to create Packages.

First, let’s define Project and Package.

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 remote Servers, and the shareable unit when collaborating with other team members via an SVN Repository.

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.

To summarize, you can’t have a Package without a Project.  You can have multiple Packages used to organize resources within one Project.

Organization of a Project should focus on your Trading Partners.  Meaning, you should have one Project for each Trading Partner, regardless of document type and syntax category.  Your Projects should be named com.YourCompanyName.clarify.TradingPartnerName. For example, if you work for the fictitious company called BigTruck and your Trading Partner is Amazon, your Project name should be com.bigtruck.clarify.amazon.

In our example, we’re using us!

Amazon Project and Package

When you create a Project, a Package is automatically created below.  This Package will have the same name as the Project, and will be found below the src folder, beneath the Project.

Amazon Project and Package Diagram

Your Package structure can be created based on syntax category, for example, a Package for your Flat File resources and another for your EDI resources.  If you’re processing two documents for one Trading Partner, you can break-down that syntax category into inbound and outbound, or inboundOrders and outboundInvoices.  

Sears Package Structure

Be aware that some names are not allowed, as they may be extensions of objects in Cleo Clarify. Many of those objects are Routes, which do not allow you to name your Packages with “inboundEdi” or “outboundEdi”.

If your objects pertain to that syntax, or in our example for our Seas Projects and Package structure, make sure you place those objects in the correct Package.  The default Package that was created, the one with the same name as your Project, should contain your resources that are vital to that Trading Partner but may not be syntax specific.  For example, your Trading Partner object, or perhaps a Next Number that can be used in several Packages.

When it comes down to your created Packages, your Inbound EDI Route should go into your inbound Package. Your Outbound EDI Route should go inside of your outbound Package.  Those are pretty obvious, but some others are..

Inbound Package

  • Inbound EDI Route
  • Inbound EDI Schema
  • Inbound EDI Business Process
  • Inbound EDI Ruleset

Outbound Package

  • Outbound EDI Route
  • Connection Business Process
  • Outbound EDI Business Process
  • Application Interface
  • Control Number Generator
  • EDI Enveloper

If any of these objects are generic and can be used by multiple Trading Partners, they should be maintained and referenced from your Core Project.


By: on