views:

40

answers:

1

Hi Gurus,

I am working on a project where I am importing in orders from an external vendor. I will need to validate the information prior to loading it into our ERP system and then send a response with shipping information once we have processed and shipped the order.

I wanted to see how others would track the steps necessary to make this happen. Not looking for code just wanted to get an idea of how others would track where they are at in the process? Do you write records for all the necessary steps..do you use flags, etc.

We currently use C#, Oracle DB, and BPEL

Process Steps:

  1. Import order information into staging table.
  2. Validate order information (as much as possible) prior to loading into ERP system.
  3. If validation fails send notification, if passes send to ERP.
  4. Perform further validation on order (sufficient QTY, etc). If fails send notification to vendor...if passes let proceed through to shipping.
  5. Ship Order.

Just wanted to see how others would approach tracking these steps?

Any info/suggestions would be greatly appreciated.

--s

A: 

Well, you want to hold as much information as possible, probably. I'd use a state-based system to determine where the object is.

The next question is do you wish to optimise it by having the objects of various states in different tables. It's good, because it means queries are faster (no where clauses), it's bad, because you need to duplicate tables (i.e. columns).

Probably, I'd have one table, something like 'tblInProgressOrders' and 'tblAcceptedOrders' (whatever names you wish). In the 'InProgress', it would have a 'CurrentState' what determins what is what. In accepted orders you may be a bit of metadata, but it's implied that if it's in there, it's accepted.

HTH.

Noon Silk
That is basically inline with what I was thinking. I wwould then be able to know waht step I am on what failed, etc. If they fix the error and resend I could use flags that would keep the original, but make the process think it needs to start over.
scarpacci
Not necessarily disagreeing with the idea of multiple tables - but note that it might get complicated if you want a child table - either you have to omit the FK constraints or have separate child tables for each parent.
Jeffrey Kemp
Good point Jeffrey...I will keep that in mind. Thanks for the input.
scarpacci