Problems with Throwaway Code in Transaction Processing Systems
Blog: KWKeirstead's Blog
It seems pointless in any transaction processing system to . . .
1) go to the trouble of only allowing data to be recorded via Official Interfaces,
2) go to the trouble of building Transaction Histories that allow recall of Sessions, viewing of data, as it was, at the time it was collected, on the Form versions that were in service at the time,
then process transactions using code you build on-the-fly and
then throw away.
Part of the purpose of a Transaction History is to be able to re-trace the processing in the event of errors.
The problem is wider than this – it extends to any local or remote system or application where you do not have absolute control over source code changes (i.e. an archive of all versions of the source).
So, the only option when accepting data from any local or remote systems, not part of your main transaction processing app, is to carry out reasonableness checks that confirm that processing results are within range.
This is difficult, (i.e. if the temperature today is 32 degrees F and you go to an app that maps your temperature reading to degrees C and you see 300 degrees C, you know something is not right. But, if you get back 1 degree C, that, too, means the processing is not right).
A partial remedy in a BPMs is to include pre-processing and post-processing rules at process steps to carry out real-time “audits” on outgoing and incoming data.
Pre-processing: “Is it OK to engage processing at this step?”
Post-processing: “Are the calculated results from the local or remote external
app within boundary conditions?”
Comment:
Note the reference to “official interfaces” above.
No organization today will allow data to be “poked” into its data structures.
The reason is that such actions bypass in-line security.
It follows that the only acceptable approach to shipping/receiving transactions between any two systems involves use of an agreed-upon data transport format that publishers generate and subscribers import, presumably using appropriate pre-processing rules.
The usual range of “official interfaces” includes
- Direct keying at traditional User Interfaces (user logs in, loads an app,
engages whatever processing options are available at the application
menu bar and icon bar). - Portal access using a range of devices that are able to get to the Internet via a browser.
- Data exchange in/out of a generic data exchanger (using “push” or “pull”).
Leave a Comment
You must be logged in to post a comment.
