Alan Faulkner's Forefront Security Blog

Order Adapter’s Status Values

I hope to shed some light around our Orders Adapter’s use of the Status value in a Purchase Order. The Orders Adapter has the configuration options for two values:

1. Status From
2. Status To

In a Purchase Order, there is only one status value. When the honorStatus field is set to true in the web.config (by default, this is true), this value is controlled by the two tables in the transactions configuration database, which are AllowedStatus and StatusManager. The AllowedStatus table controls the allowable values that the Status field can hold. If a value is not present in the AllowedStatus table, the Purchase Order cannot be set to that Status value. The StatusManager table controls what application/client can change a Status value. Let me illustrate:

Let’s say that we have the following values in the StatusManager table:

Let’s say we just created a new Purchase Order, which, by default, it’s Status value is NewOrder. From the table above, the Site application and LOB Adapter client can change this Status message to any value that is contained in the AllowedStatus table. Let’s say that the Site application changed the Status value from NewOrder to Submitted. If the LOB Adapter attempts to change the Status value of that same order (which current Status is Submitted), it will not be able to since the LOB Adapter is not in the StatusManager table for that Status value (Note: this is particular to this example, by default, the LOB Adapter does have access to change the Status value if it’s currently Submitted via the settings in the StatusManager).

The Orders Adapter allows the customer to change the Status value when exporting Orders from Commerce Server by specifying a “Status To” value. Further, the Adapter allows customers to filter exported Orders by specifying “Status From”. Let me give an example, let’s say that the following values are set in the Orders Adapter:

• Status From -> NewOrder
• Status To -> Submitted

When the adapter is enabled and performs an export, the adapter will query Commerce Server Orders system for all orders that have the Status value equal to “NewOrder” then as soon as it exports the message, the adapter calls Commerce Server to change the Status value to “Submitted”. This is done for every Order that is exported. This case is a one to one mapping.

We can also have more complex values of the Status field. For instance, let’s say we have the following (just for illustrative purposes):

• Status From -> NewOrder, Submitted
• Status To -> Submitted, InProcess

In this case, it’s a many to many mapping of “Status From” to “Status To” values. The adapter will query the Orders System for all orders that have the Status value equal to “NewOrder”, then as soon as it exports, the adapter will call Commerce Server to change the Status value to “Submitted”. Also, it does the same thing for the Status From equal to Submitted. The adapter will export all orders that have the Status value of “Submitted” and then change those values to “InProcess”.

We can go even further, for instance:

• Status From -> NewOrder, Submitted
• Status To -> InProcess

In this case, it’s a many to one mapping. The adapter will export all orders that have the Status field equal to “NewOrder” and “Submitted” and once exported, change those values to “InProcess”.

To summarize, for the Status From and Status To fields, we have the following relationships, which settings are controlled by the AllowedStatus and StatusManager tables:

• Many to Many
• Many to One
• One to One

Clear as mud?

Hope this helps!

Alan