Introduction

GUIDs in Boomi give every message or transaction a unique reference. Teams use that reference to correlate records, trace failures and prevent duplicate processing. In this article, you will add a small Groovy script to a Boomi process and write the generated value to a Dynamic Process Property.

The script uses Java’s UUID library. Therefore, it does not need an external service or connector. It runs inside the Boomi execution and creates the identifier immediately.

Why generate a GUID?

A GUID works well when the source system does not provide a reliable identifier. For example, you can create one before sending a message to several target systems. Each system can then log the same reference.

• Correlation: Connect related messages across APIs, queues and applications.
• Tracing: Find one execution quickly in logs and dashboards.
• Idempotency: Help a receiving system detect duplicate requests.
• Record identity: Give a new object a unique technical key.

The Groovy script

The following script generates random GUIDs in Boomi. It calls UUID.randomUUID() and converts the result to text. Next, it writes that text to the DPP_RandomGUID Dynamic Process Property.

You can rename the property if your process uses another naming standard. However, choose one clear convention and reuse it across integrations.

Implementation steps

1. Add a Data Process shape where the process needs the new identifier.
2. Choose custom scripting and select Groovy.
3. Paste the script or reference the shared script component.
4. Run the script before any step that needs the GUID.
5. Read DPP_RandomGUID in mappings, connectors or message headers.
6. Test the process with several executions and compare the values.

First, run a small test set. Then, confirm that every execution creates a different value. Finally, search the process log with one GUID to verify the tracing flow.

Choose the correct property scope

A Dynamic Process Property fits one execution-level identifier. In contrast, a Dynamic Document Property fits a value that must differ for each document. Choose the scope before you place the script.

For example, one batch can share a correlation ID while every document receives its own message ID. In that design, keep the correlation ID at process level and the message ID at document level. As a result, operations can trace both the batch and one individual message.

Operational recommendations

Do not generate a new GUID after every retry. Otherwise, the retry loses the original trace. Instead, create the identifier once and preserve it through the complete flow.

In addition, send the GUID to your logs, API headers and error messages. This makes support faster because every platform exposes the same reference. Also document the property name so another developer can reuse the pattern safely.

Conclusion

GUIDs in Boomi provide a simple foundation for correlation and troubleshooting. The Groovy script keeps the implementation small, while the property scope controls how long the identifier lives. Therefore, define the scope clearly, generate the value once and carry it through every downstream step.