Following One Order

A customer places an order for pens, notepads and clips. The website knows what the customer selected. A catalogue knows the prices. A database must remember the accepted order. Fulfillment needs to learn that the order exists, even if the connection fails at an inconvenient moment.

Those are separate responsibilities. Mule gives us a way to connect them and to describe what should happen when one of them cannot finish. Suppose the warehouse receives the order and its reply never reaches us. Sending the request again might repeat work that already happened; reporting failure might tell the customer to abandon an order that is being fulfilled. Choosing between those two answers means knowing what each system has done and what we can still find out. That is the problem the book builds up to, and it starts from a much smaller one — receiving an HTTP request and returning a greeting.

Learn through the ACB canvas

The runnable chapters use Anypoint Code Builder’s flow canvas, component panels, DataWeave editor, debugger and Testing view. Mule still stores the application as XML, but the lessons describe the visual controls used to change it. SQL, RAML, YAML and DataWeave remain text where those languages express the contract or transformation. Logging and domain configuration are explicitly identified text-editor exceptions.

Download the complete ACB companion snapshot, then follow chapter 1’s pinned editor setup. The archive contains all local checkpoints and the separate platform/workshop artifacts. Each chapter names the folder to open and the result to check. Use the downloadable snapshot for these editor exercises; the per-example GitHub links identify the original companion source locations and may not yet include the ACB metadata adaptation. Cloud control-plane operations remain browser or release-terminal tasks; opening their files in ACB does not establish a deployment.

What you need before starting

You should be comfortable reading a small JSON document and using a terminal. Basic HTTP knowledge helps: a client sends a method, a path, headers and sometimes a body; a server returns a status and a response. You do not need prior Mule experience or functional programming. The first DataWeave lessons teach the expressions the application uses before asking you to combine them.

MuleSoft names the integration platform. Mule runtime is the software that executes our flows. Anypoint Platform supplies services for managing APIs, deployments and operations. Anypoint Code Builder is the editor used here. You can learn the local runtime without first learning every platform screen; the platform becomes useful once there is an application to manage.

The local exercises need Java 17, Maven and a licensed or valid evaluation installation of Mule 4.12.3. The companion repository contains the application source, fixtures, dependency services and checks. It does not redistribute Mule. Appendix A lists the exact versions and the setup details, including the packaging workaround used by this edition.

The application grows in stages

Chapters 1–6 stay inside a small flow. You receive a request, inspect its event, build a response, calculate an order total, retain a value and test the result. Each step gives the next example something familiar to build on.

Chapters 7–14 turn those skills into an order API. The API checks the command, calls a controlled catalogue, calculates from the catalogue’s prices, stores the order and reads it back. This first service is deliberately local. Its database is in memory, its caller context is synthetic and a repeated order is a conflict. You will know exactly what it does before adding a stronger recovery promise.

Chapters 15–22 introduce files, sequential processing, scheduling and parallel work. We then give repeated requests a stable meaning, put publication intent in a database transaction and inspect what happens when delivery repeats. Batch and caching follow the simpler mechanisms they build upon.

Chapters 23–27 address identity, TLS, secrets, policies, deployment, investigation and release automation. Some of those exercises need an Anypoint environment or an identity provider. Their setup and evidence are separate from the local runs. Reading a policy configuration is useful, but it is not an enforcement test.

The last three chapters use the completed application to discuss API boundaries, a separate gateway and acceptance under failure. The final recovery exercise introduces no hidden persistence or dispatcher implementation. You will already have seen those pieces work.

How to use the examples

Each worked example has a name and a number in reading order. Its source link identifies the matching companion checkpoint. A checkpoint is a complete Mule project; you can open it directly rather than reconstructing a project from fragments scattered through the book. Some chapters keep an earlier flow alongside the new one so you can compare them.

Run one checkpoint at a time. They share the same application name and local HTTP port. The provided dependency service uses a different port and serves only synthetic data. Setup and failure-injection endpoints are confined to the local teaching application; they are not public API operations to deploy unchanged.

The main order is A-1001: Dana’s four pens at 2.50, two notepads at 6.00 and ten clips at 1.00. The three line totals are 10, 12 and 10, for an order total of 32 USD. Early calculation exercises carry prices in the fixture so the arithmetic is visible. The later order command carries only product identifiers and quantities; its prices come from the catalogue. Those are two named representations of the same business order. The order is deliberately ordinary — you can follow the business without learning a new industry, which leaves room to concentrate on the integration.

Read each result beside the example that produced it, then make a small change before moving on. The examples become easier to follow when you stop at a processor and work out what its input means: after a customer lookup, is the payload still the order, and where did the lookup result go? A correct response is useful evidence, but understanding how that response was assembled is what makes the next change less mysterious. Exercises put their questions before the answers. When a later chapter returns to an example, it names that example and explains the new behavior being added.

Appendix A records which examples were run and on which stack. Specialist format, XA/domain and synchronization workshops follow the main chapters. DataWeave in Depth continues the language teaching; you do not need to finish that second book to understand this one.

Next: Hello Mule, One Request at a Time