ARK proposition - Workflow reusable functions - Groovy templates
How to facilitate workflow script development?
If you’re anything like us, you’re struggling with workflow development best practices.
While we try to enforce best practices, we often have workflow developers coming from different backgrounds and different habits.
| Approach | Pros | Cons |
|---|---|---|
| Raw Collibra APIs 😐 |
OOTB Portable Well supported |
Quite verbose Difficult to use Prone to type errors Very inconsistent usage |
| groovy-lib 😐 |
Easy to use Less errors |
Horrendous to deploy/manage Workflow not portable/compatible Versioning is a nightmare Arcane and not well supported Performance issues (all groovy-lib code is appended to EVERY. SINGLE. SCRIPT TASK.) |
| Snippets/Templates 😀 |
Easy to use Less errors |
A bit difficult to set up and keep up to date Requires manual action for every single script task |
Let’s take a simple example of setting attributes on an asset.
1. Using Collibra APIs In this method, every developer needs to define its own functions, which requires skills and experience. This is particularly difficult for junior resources and 10 developers will implement their code in 10 different ways. 2. groovy-lib In this example, reusable functions are created in the customizations folder, into multiple groovy files. Upon starting DGC, collibra will open every .groovy file and append the content to every single script task of every workflow definition. This is a particularly heavy approach. In addition, it requires the environment to be restarted to load new function: every updated requires a restart. 3. Snippets/Templates At this time, we are leaning towards making it as easy as possible for developers to reuse code without too much hassle. Here are some propositions, what do you think?In Eclipse, it is possible to define reusable “Templates” that allow to inject code snippets into any script file.
Clicking on Window > Preferences > Groovy > Editor > Groovy Templates, it is possible to define new snippets ready to be injected. It even provides possibility to define variables so that we can timestamp when the code was generated, helping keep track of potentially outdated functions.
Here’s a demo:
arthurburkhardt
Posted 3 years ago · Edited 1 year ago·Last reply 1 year ago
1 comment
Steven Cottren
·1 year ago · EditedI have only just discovered the groovy-lib option is available for us, and agree that there are challenges with the first 2 options, with the third option no longer on the table when using Collibra Workflow Designer. I'm still contemplating using groovy-lib for the 2 or 3 functions that we use in most scripts (but will need to discuss this with the administrators). One method I started to use, (while not solving the issue, does allow for re-use in Collibra Workflow Designer) is to add unconnected script tasks within the workflow that hold the various pre-canned functions and their API calls. How this helps is that while the code cannot be used from the script container, means that it doesn't need to be re-written by each developer. I can develop it once, and share across with other developers. Note I re-colour the script task so that it becomes its own library colour and no-one is confused by its presence. With this option, you could start to segregate the types of functions used into specific categories, and have multiple libraries available for others.
Obviously a groovy-lib compilation based on referenced libraries would be a very cool option.