Question: **Short Version:**

How do you collect the results of a complicated operation that is spread over several objects?

**Long Version:**

I am developing a data exchange system that will push customer orders from one system to another system. This will be done via an API and unfortunately this require 12 individual steps to be completed successfully in sequence before an order can be reported as successfully transferred.

Although each step can (and has) been broken down into individual units of code, each step HAS to be completed in sequence and some steps depend on the result from previous steps.

Is there a suitable design pattern or combination of patterns that fit well for this particular problem? If each step is dependant on the previous step then whats the best way to make it aware of the previous steps result.

I was thinking of a Composite/Macro Command design or perhaps modelling the OrderPush process as a Finite State Machine although I was hoping to keep it more simple.

This is a question about system design so there is no need to go into detail on what the API is or how it works and I'm only expecting to be pointed in the right direction.

The process is to read relevant data from a local system and push to a remote system via XMLRPC.

The steps are:

* Create Customer
* Create Order (header record)
* Create Order Lines
* Confirm Order (this creates an invoice)
* Find Invoice
* Confirm Invoice
* Create Payment
* Find Journal Item (Journal item relates to the invoice so that the payment line can be tied to the invoice)
* Create Payment Line
* Confirm Payment

Each step is a single XMLRPC call that will either succeed or fail. And this is the crux of it. If the customer failed to be created then none of the other steps will work. Similarly if the order failed to be created then the other steps will either fail or not be able to tie together (i.e. I should obviously stop execution if any previous step fails).

So has anyone got any tips?

Answer: 
For anyone who is interested, I did finally stumble across a design pattern that suited my needs.

My question could have been condensed down to simply:

How do you collect the results of a complicated operation that is spread over several objects?

(I have now edited the question)

The answer was the Collecting Parameter Design Pattern.
<http://sourcemaking.com/implementation-patterns/collecting-parameter>

There are not too many examples in the PHP world although its not a very complicated concept. Common sense really but I guess thats what all Design Patterns are.

The way I solved it was by implementing each separate operation using the Command Pattern which abstracts a single operation so that I can invoke it using a common interface (i.e. a "process()" or "run()" method).

Given I now have 12 operations that I can invoke with their own process() method, I trigger them in order and I pass in a generic object (called CollectingParameter for clarity) whose job is simply to record the result of each operation (so the CollectingParameter object must be returned by each process() method). The CollectingParameter object gets passed into the next operation which will then have access to all of the results it needs from the previous operations.

```
$operationList = array(new CreateCustomer, new CreateOrder, new CreateOrderLines ... etc)
$collectingParameter = new CollectingParameter;
foreach($operationList as $operation) {
    $collectingParameter = $operation->process($collectingParameter);
}

```

Errors are logged and handled within the various process methods which leaves the process() method free to return the CollectingParameter object rather than the results of the operation.
What you really have described there is an algorithm for getting something done. 
If the order of these steps is very important but sometimes the implementation can vary then that could become a [Template method](http://en.wikipedia.org/wiki/Template_method_pattern) where the steps are static (i.e. the order has to be the same) but the implementations may vary. 

You should look at the [Command Pattern](http://en.wikipedia.org/wiki/Command_pattern) and the [Composite](http://en.wikipedia.org/wiki/Composite_pattern) to compose a tree of discrete steps that can be executed as one e.g. process(). You could also look at undo commands which could be important in your case if it fails halfway through the flow.