Lesson 5 of 6
Script collections and reuse
8 min
Listen to this lesson
Copy-pasted scripts are the Groovy version of copied mappings: one bug, twelve fixes. A Script Collection is an artifact in an integration package that bundles Groovy scripts, JavaScripts and JAR files, so flows reference one copy instead of carrying their own. SAP lists the benefits as reuse, less maintenance, smaller flows and no duplicate copies.
Creating a collection
- Open the integration package in edit mode. In the Artifacts tab choose Add > Script Collection.
- Choose Create, or Upload a .zip downloaded from another package's Design workspace (SAP says not to download it from the runtime or deployment views).
- Enter a name, an ID and a description that says what the collection is for.
- Open the collection, choose Edit, then Create > Groovy Script, or Upload an archive, a Groovy script (Script 1.x or Script 2.x), or a JavaScript, from your file system or from an existing integration flow.
- Save and deploy the collection. Flows reference the deployed collection.
Consuming a collection
Consumption is a two-step process. First, in the integration flow's property sheet, choose Resources > References > Add References > Script Collection. Collections in the same package are listed by default; the Packages list shows collections in other packages on the tenant. Second, add a Script step, choose Assign, open the Reference Resources tab and pick the collection and the script. A change to the source script is then available to every referencing step.
Versions must match
When you upload a Groovy script to a collection, you choose Script 1.x or Script 2.x; 2.x runs on Groovy 4.0.29. SAP's caution: the referenced script's version must match the Script step version, or the step is upgraded or downgraded automatically. If a step at version 1.0 picks a 2.x script, the step is upgraded. For Contoso that means migrating shared helpers to 2.x first, then the flows that use them.
What belongs in a collection, and what doesn't
| Put it in the collection | Keep it local in the flow |
|---|---|
| Helpers used by several flows: business key, masking, date utilities | Logic specific to one partner or interface |
| Code with one owner and its own tests | Experiments and one-off fixes during development |
| Stable signatures that callers rely on | Anything that changes with one flow's mapping |
Mapping custom functions are a special case. SAP's scripting guideline package keeps its mapping functions as local scripts and notes that mapping UDFs weren't supported in script collections when it was written. Check the mapping editor's Assign dialog in your tenant before planning to share mapping functions through a collection; until then, a small, well-tested local function per mapping artifact is acceptable.
| Collection | Contents | Owner |
|---|---|---|
| CMC_Shared_Scripts | Business key, masking and date helpers used by many flows | Theo's team |
| CMC_B2B_Helpers | Generic EDI helpers, such as control number formatting | B2B developer in Theo's team |
| (none) | Partner-specific rules: stay in the partner's flow or in the Partner Directory | Interface owner |
Contoso's collection layout: few collections, clear content, one owner each.
Script collections have their own Design Guidelines tab, so the upgrade-readiness and general script checks can run on the collection as a whole. Contoso runs them before every deployment of CMC_Shared_Scripts and treats an open finding the same way as in a flow: fix it, or record why it stays.
Ownership and change
A shared script is shared risk. Contoso gives the collection one owner in Theo's team, keeps a short change log in the collection description, and treats a change as a change to every flow that uses it. The transport path is the same as for flows: CMC_DEV, then CMC_TEST, where Priya forwards only after test sign-off, then CMC_PROD in the approved release window. Before a helper changes, the owner reruns the tests of every referencing flow (lesson 6).
What would you do?
Kenji's ABAP team asks Theo to put a 900-line "Lakeside rules" script in the shared collection so the other supplier flows can reuse parts of it. What should Theo do?
- A Script Collection bundles Groovy, JavaScript and JAR resources; deploy it, then reference it.
- Consume it via Resources > References > Add References > Script Collection, then Assign in the Script step.
- Script 1.x or 2.x must match the step version, or the step is upgraded or downgraded automatically.
- Share stable, generic helpers with one owner; keep partner rules local.
Check your understanding · not graded
Lesson check
1. Which resource types can a script collection hold?
2. A Groovy script step at version 1.0 is assigned a Script 2.x resource from a collection. What happens?
3. Where do you add the reference to a script collection in an integration flow?
4. From where does SAP say to download a script collection before uploading it to another package?