Re: MVC Architecture and transactions

Joe Pluta wrote:

From: Buck

The purchasing agent calls you up and places an order. Salt, pepper,
cups, ketchup packets and pencils. Your order entry catches the cups,
ketchup and pencils and your order desk tells the agent that you need a
new order for that stuff.

The purchasing agent does her magic to generate a new, proper PO and you
cause the salt and pepper order to update/process. The purchasing agent
then gives you the new order of ketchup, cups and pencils. Your order
entry validates that all those items are non-condiments. While doing
that, the head office calls in and adds ketchup packets to the list of
condiments. They're talking to a different person, in another office,
completely unaware that one of the purchasing agents is giving you an
order at this moment.

None of this has anything to do with commitment control, right? You
shouldn't be actually posting the order unless you do another validation.
So the real issue is that, once the purchasing agent hits the submit button,
there is a cycle where you validate the order then immediately post it. It
is this tiny window where a master file change (in effect, a serious change
in business rules) might cause a prevalidated order to be posted
incorrectly.

How do you validate an order like this? Loop through the subfile and set a condiment=yes flag if you find an item in the condiment file and a condiment=no flag if the item under scrutiny isn't in the condiment file. At the end of the loop, if both flags are on, you have a non-compliant order.

When the customer agreement is first implemented, there were many, many changes to the condiment file. Live, during the day, whilst orders were being phoned in. We found that there were enough orders going out wrong that we had to verify again whilst we were updating. This isn't difficult, it's

dow
rrn chain sfl
item chain condiment
if condiment and non-condiment flag is set, error out
if non-condiment and condiment flag is set, error out
exsr update
enddo

CC comes in when you've validated item 1 and done UPDATE. Then you attempt to validate item 2 and it fails. ROLLBACK then brings the entire transaction back to a known state and the order desk can tell the purchasing agent that ketchup is a condiment.

(Side topic: You say this as though management expects such a change to
happen instantaneously and completely. What about any outstanding orders
prior to this that have ketchup going to the wrong warehouse? Did you fix
those? I bet not. So this one order that was in process simply follows all
the rules that were in place MILLISECONDS prior, just like all the other
orders that day.)

The discussion was had, and our QoS agreement was modified to note that items changing status had to be invoiced properly after the item change timestamp. We couldn't control what was already enroute on the trucks, either.

And if you're adding a second validation pass just to catch possible head
office changes that occurred during the past 30 milliseconds, then you
really are adding a lot of overhead to your process, and I don't think
commitment control is really the way to handle it.

A CHAIN and two compares isn't a lot of effort to secure millions of dollars worth of sales. CC lets us undo all the updates scattered across ye-gods files and lets the order desk segregate out either the condiments or the non-condiments as the purchasing agent required.

Still not seeing it, Buck. To me, the right way to handle major business
rules changes such as this is to write a program that checks all outstanding
orders to make sure they match the new business rules, and then provide an
exception report to handle them. This would catch all windows.

Exception reports running in batch are a good answer for some sales environments, but for a JIT situation, the time added to the process was considered excessive. We basically shipped goods to the customer exactly as each individual store needed it. They didn't keep hardly any inventory; a tremendous savings for them. We got their business because we were flexible enough to implement their requirements for a real-time order desk with real-time availability. We were able to do it because it took less than a day to conceive, mock, code, test and implement a solution using commitment control. We were receptive to their needs in a way that their management could readily see, and that was worth more business in the future.

> Yes, commitment control has its uses, but facilitating the change of
> business rules isn't one of them, I don't think.

Fair enough. What uses do you use commitment control for?
--buck