How to develop distributable packages (modules) with Origam?

A set of reusable functionality should be developed into a package that can be distributed across other Origam application.
How can this be done ?

Any package developed using ORIGAM can be redistributed, there are no technical limits. Nevertheless, there are a few things you should take care of.

This list might not be complete. I welcome any other thoughts or experience you had developing reusable ORIGAM packages.

Take Time to Design an Architecture

Once the package will be used in other projects, it will be much harder to refactor anything. This is even more important if the package will be used by other companies. But even if used only internally, you never know what you will want to extend (and you will) in other projects. So when somebody will add some extra fields to an entity, you will have hard times refactoring this entity to something else.

You should also think of what are the basic parts that will be easy to share among other projects and what are the specifics of your first project you are building the package with. Is it only the pure data model you provide? Or will you include all kind of business logic including some parameters used to customize the behavior? The more complex the reusable package is the easier it might be to start-up in another project but it might be much harder to customize something because of the rich functionality.

Try to think more about what are the potential uses of the package.


It is a good idea to set up a wiki with some guidelines about how to implement the module. You should also say what usage you planned for and is fully supported and what is definitely not. The last thing you want is other developers or customers twisting the functionality and then reporting problems about things out of the package scope.

Naming Conventions

You should be more careful about naming because you will mix e.g. your data model with some, yet unknown, project. You should probably name your entities (and other mode elements) using some prefix, e.g. MyModuleEntity1.

Creating an Internal API

There are different approaches to this but it is definitely a good idea to advise the future developers about how you expect data to enter the module (and you should include this in your documentation). It can be one or more of the following:

  • REST API – the way how to communicate with your module is us using API’s. This is definitely the safest way since you will not expose any internal functionality to the outside world. But it is not so great for reusing a functionality using internal ORIGAM features.
  • Sequential Workflows – you will create some workflows which will be the entry points for anything other packages will try to get from your module. You will not allow others to touch directly your data entities. This can be useful but you should always take care that if you allow extensions of your data entities (you should document if this is allowed or not) that your sequential workflows will expect additional content sent to them and save it properly.
  • Work Queues – you might create a very scalable entry point into your application using queues. Putting a message into the queue will result in saved data, a response message in another queue or whatever.
  • State Machine Events – you might hide your functionality behind state machines and data events. E.g. the application will directly save data into your module’s data entities and all the business logic will happen in OnRecordCreated etc. events. This way the developer of another application can design screens on top of your entities, let the user save the data directly but the magic will happen behind the scenes (e.g. assigning sequence numbers, updating other records, sending notification messages, etc.).

User Interface

You might or might not include the basic user interface. You should always consider that it is possible to create alternative GUI (screen or screen section). So when the developer of another application will extend your data entities, he or she will probably also extend your GUI. When doing an update to your reusable package, you will need to properly notify the developers that you e.g. added a new field into an existing screen so they would also include it in their alternative screens.