Sample Order Processing System
The Sample Order Processing System is intended to be an example that can be used in a variety of settings to teach developers how to work with the platform.
The following diagram shows an order processing system. It is designed to be as simple as possible, but at the same time contain many of the "interesting" features that need to be demonstrated.
About the Object Relationships
The Sample Order Processing System is a simple-as-possible system that has an example of each kind of relationship.
One-To-Many Relationships
A Customer can have multiple Orders, and an Order can have multiple OrderItems. Those are One to Many relationships (1:N).
Here, for example, common information about a particular customer can be stored in one place (for example, name and shipping address) rather than being repeated in each order.
Many-to-One Relationships
From the perspective of an Order, there is a many-to-one (N:1) relationship with the Customer object.
Since the customer field is a Lookup field, someone taking the order will select the customer from a Lookup field. (For a new Customer, they'll be able to add a new record on the spot.)
Similarly, a product entry may be referenced in multiple Orders, so there is a many-to-one (N:1) relationship there, as well.
Many-to-Many Relationships
The last relationship shown in the diagram is slightly more interesting. In this model, multiple tags can be attached to an order, and the available tags are completely under the user's control. (A pick list, in contrast, need to be modified by a designer.)
An order to install a computer system, for example, could be marked to specify that it was for a developer or for the sales department. Depending on the recipient, the machine would get a different kind of machine, a different operating system, and a different set of utilities, by default. Or the order might be marked as a high-priority, "rush" job.
We now have a situation where one order can have multiple tags, and any given tag can be applied to multiple orders. That situation constitutes a many-to-many (N:M) relationship.
That relationship is modeled using a Junction Object--an object in which each record contains Lookup fields for other objects. In this case, each record in the junction table contains an Order identifier and a Tag identifier. With those Lookup fields, an Order can map to multiple Tags, and a Tag can map to multiple Orders.
Note: Structurally, the OrderItems object is very similar to the Orders_Tags Junction Object. But since it wasn't actually defined as a junction object, the platform doesn't recognize it as such. That's desirable, because even though the objects are similar in structure, they serve different purposes. When you are looking at a Tag record, you'll have a Multi Value Lookup that lets you select multiple orders to apply the Tag to--a handy capability to have. But when you are looking at an item in the ProductInventory, you don't want to retroactively apply it to Orders. That's now how things work!
Learn more: Object_Relationships
Using Data Policies
Data policies provide powerful tools for data validation and manipulation. For policies designed to work as part of the Order Processing System, see the Data Policy page, with particular attention to the section, Invoke a Java Method From a Data Policy.
Using Composite Objects
A lot can be accomplished by accessing the objects in that system, one-by-one. But it is also possible to work with groups of related objects. Using the Composite Object APIs, for example, it is possible to add a new order, add the order items, update the customer address, and update the product inventory, all in a single transaction.
To do that kind of sophisticated processing, you need the ability to write programs that use the platform's APIs, and you need a solid understanding of the relationships between the objects.
Learn more: