Testing Boomi processes during development

The most common way to test an integration during development is also the least useful: wire everything up, place a test order in the e-shop, and see whether it shows up in the ERP. If it does, great. If it doesn’t, you have no idea where it went wrong, and you need another test order to find out. This article describes a better way to test flows as you build them, then shows how to do it in Boomi.

Why “run it end to end and look” doesn’t work

It’s slow. Each attempt needs a real action in a source system and a check in a target system.
It’s not repeatable. The second test order is never exactly the same as the first, and incremental flows only pick up “new” data once.
It hides the middle. You see the input and the result, not what each step did to the data.
It only tests the happy path. Nobody turns off the ERP to see what happens when it’s down.
It has side effects. Test orders reach systems you didn’t intend: the ERP, the courier, the customer’s inbox.

The pattern: fixed input, visible steps, forced failures

Good development testing has three ingredients:

Fixed, saved input. Inject a known document at the start of the flow instead of fetching it from a live system. Keep a small library of these samples: a normal order, an order with many lines, an order with Greek characters and a long address, an invalid one.
Visibility at every step. See the data after every transformation, so a wrong value can be traced to the step that produced it.
Deliberately triggered errors. Test what happens when a lookup fails, when validation rejects a document, and when the target system returns an error.

Doing it in Boomi

Boomi’s Test mode runs a process from the process editor on a runtime enabled for testing, and keeps the documents that passed through each shape so you can inspect them. Combined with fixed inputs, it covers all three ingredients.

Step 1: Set up a test runtime

Test mode needs a runtime that is allowed to run tests: a local Atom on a development machine or server, or a test cloud runtime available to your account. Use a runtime attached to a test environment, with connections that point to test instances of your systems. Never run Test mode on a runtime whose connections point to production.

Be aware that Test mode is designed for development: it has limits on the volume of data it processes, so use small representative samples rather than full production batches. Check the current documentation for the exact limits.

Step 2: Inject fixed test data

There are two common ways to start a process with known data instead of a live connector.

A Message shape. Set the Start shape to receive no data, then add a Message shape containing the sample document. This is the quickest option and keeps the sample inside the process. Remember that the Message shape treats curly braces as variable placeholders, so JSON content has to be wrapped in single quotes to be read literally.

Files from disk. If your test runtime is a local Atom, you can use the Disk connector to read sample files from a folder on that machine, for example C:\boomi-test\orders\. Each file becomes a document, so dropping in several samples tests several cases in one run. This keeps the samples outside the process, where they can live in version control.

A clean way to organise this is to separate the source from the logic:

Main process:   [e-shop connector] ──► Process Call: "Order logic" ──► [ERP connector]
Test process:   [Message / Disk]   ──► Process Call: "Order logic" ──► [Stop, or a mock]

The logic (mapping, validation, lookups) lives in a subprocess that both the real process and the test process call with the Process Call shape. You develop and test the logic with fixed data, and the real process only adds the connectors around it.

Step 3: Run and inspect each shape

Open the process and click Test. Choose your test runtime.
Watch the run on the canvas. Each shape shows how many documents went in and out.
Select a shape to see the documents it produced. Open a document to view its content and its document properties.
Follow a document through the flow. When a value is wrong, the first shape where it is wrong is where the bug is.

Typical things to check: does the Map output contain the expected fields; did the lookup return a value; did a Decision send the document down the branch you expected; how many documents reached the end compared to how many started.

To make the run easier to read, add a Notify shape at key points with a short message such as Order {1} mapped, payment method {2}, using document values as parameters. The messages appear in the process log of the test run.

Step 4: Test the error paths on purpose

The happy path is usually fine. The bugs live in the other branches. Build samples that trigger each one:

Validation failure. An order with no customer ID or a negative quantity. Check that the document is stopped and that the error message is useful.
Unknown code. An order with a payment method that isn’t in the lookup table. Check that it fails loudly rather than reaching the ERP with an empty field.
Target error. Make the target call fail: point the test connection at a non-existent endpoint, use a deliberately invalid record the test ERP will reject, or replace the call with an Exception shape in a test copy. Check that the Try/Catch shape catches it and that your error handling (logging, notification, retry) behaves as designed.
Partial failure. Send three documents where one is invalid. Check that the two good ones still go through, if that is the intended behaviour.

For how the error handling itself should be designed, see Error handling and retries in Boomi.

Step 5: Keep the samples

Once a sample has been useful, keep it:

Store sample files in a shared location or in version control, named after the case they cover, for example order-greek-long-address.json or order-unknown-payment.json.
Record the expected result for each one, even informally at first: “maps to 3 lines, payment method 07”.
When a bug is reported from production, turn the problem document (anonymised) into a new sample.

These samples become the input for automated regression tests later, as described in Regression testing Boomi integrations before deployment.

Before you go live

Remove test shortcuts from the real process. Message shapes with sample data and test-only branches belong in test processes, not in the deployed one.
Check that connections are environment-specific. Use environment extensions so the same process uses test endpoints in test and production endpoints in production.
Run one controlled end-to-end test. After component testing, one real order through test instances confirms the connectors and credentials.
Mask personal data in samples. Samples taken from production must not carry real customer names, emails or VAT numbers.

Summary

Testing while you build is faster and finds more bugs when the input is fixed, every step is visible and errors are triggered on purpose. In Boomi, a Message shape or Disk connector supplies the input, a subprocess keeps the logic testable, and Test mode shows the documents at every shape. For the wider picture of integration testing, see our testing integrations guide.