Problems with Throwaway Code in Transaction Processing Systems


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,TransBin
     

    then process transactions using code you build on-the-fly and
    then throw away the code.

Part of the purpose of a Transaction History is to be able to re-trace the processing in the event of errors.

The problem goes beyond throw-away-code – 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 practical option when accepting data from any local or remote systems, not part of your main transaction processing app, is to carry out incoming data 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 position 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 envelope that publishers generate and subscribers import, presumably invoking appropriate pre-processing rules.

The usual range of “official interfaces” includes:

  1. 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, then logs out).
  2. Portal access using a range of devices that are able to get to the Internet via a browser.
  3. Data exchange in/out of a generic data exchanger (using “push” or “pull”).

About kwkeirstead@civerex.com

Management consultant and process control engineer (MSc EE) with a focus on bridging the gap between operations and strategy in the areas of critical infrastructure protection, major crimes case management, healthcare services delivery, and b2b/b2c/b2d transactions. (C) 2010-2019 Karl Walter Keirstead, P. Eng. All rights reserved. The opinions expressed here are those of the author, and are not connected with Jay-Kell Technologies Inc, Civerex Systems Inc. (Canada), Civerex Systems Inc. (USA) or CvX Productions.
This entry was posted in Database Technology, Software Design, Software Source Control. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s