Blog Posts Business Management

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

    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

  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).
  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”).

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="https://www.businessprocessincubator.com/content/problems-with-throwaway-code-in-transaction-processing-systems%EF%BB%BF/?wpfpaction=add&postid=86193&feed=html" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples

BPMN.org

XPDL.org

×