A Modern Transaction Architecture

A Modern Transaction Architecture

Now consider modern Payroll application design. Hours load automatically (from time clocks or spreadsheets - it doesn't matter), and the payroll checks are produced behind the scenes.

Consider the Payroll application as typically designed. The object is to convert hours worked into paychecks while calculating taxes, benefit deductions, and garnishments. The work flow is broken into a series of segments: hours entry, payroll calculations, verification, check printing. Each step is performed for the entire payroll as a batch and must be performed in sequence. If at the end one employee’s hours are in error, the entire payroll must restart the workflow and complete it in sequence. Provision is made to calculate a single paycheck, but only by exception. Throughout the process, the user interface constrains the user to this single work flow in a manner the payroll programs require.

Now consider modern Payroll application design. Hours load automatically (from time clocks or spreadsheets – it doesn’t matter), and the payroll checks are produced behind the scenes. The user is notified that hours are available, and alerted to problems with individual checks. The user corrects the problems where they occur and recalculates individual employee checks as needed. By comparison to past payrolls the user confirms that no undetected problems remain. The user interface in this modern work flow provides control to the user, who is no longer constrained by the technical requirements of batch processing. The result is accurate payroll with less user effort.

Roy Fielding proposed a modern approach to application architecture that complements this modern work flow—HATEOAS using RESTful services.

HATEOAS, an abbreviation for Hypermedia as the Engine of Application State, is a constraint of the REST application architecture that distinguishes it from most other network application architectures. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. In a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).

The challenge is to unpack that definition (with apologies to Roy Fielding for any mistranslations) and relate it to creating paychecks (or other day to day tasks of a modern ERP).

A key feature is that it is not constrained by what happened before or what is to happen next, it is stateless. The implication is that the user can work at any point in the work flow, in any order they choose free of a sequence imposed by the server application. The user can calculate pay before loading vacation and sick hours, it is up to the server application to alert the user that some checks may need recalculation after the missing hours are added.

All interaction is through hypermedia, a link plus XML containing any needed data elements and metadata (the description of data elements). The user (via the user interface) sends a link and associated XML to the server. The XML contains the full knowledge of what the user is asking the application to do: search, update, query, etc. The application server returns XML as a response. This XML contains the search results, alerts, lists plus metadata (to tell the user interface how to handle the response). The metadata also includes the links for further action by the user. This provides the ability for a user to search for an employee, then click on a link in the search results to view vacation taken, approve or reject vacation hours requested for this payroll, and adjust this paycheck as needed.

The links are the key to modern applications. Links provide a stateless communication, with context in the XML, that allow the server application to perform work at the user’s request. The structure of acceptable links is known as the API. The API defines links which are complete, self-contained communications. The user interface (or client) requests and receives links in the same way an internet browser does. The browser doesn’t know one bookmarked link leads to a shopping site and another to movies, it simply lets the user click on a link and allows the response to instruct it in what to do. To a browser, an API is simply a set of potential links a user may click on. On the other side, the application server receives and responds to links the way a web server does. The API describes the path to the application server and the types of links it is prepared to respond to. As with a web server, this works beyond the walls of the application. Any authorized application may utilize the API to accomplish work. For example, an insurance provider may link to query whether any new dependents should be added to enrolled employees in their own system.

The application server itself can be anything, no one will ever see it since the API is what the world sees. This means that a legacy application can sit behind the API as easily as a shiny new one, provided the legacy application is not too dependent on controlling the work flow to operate. This allows developers to create the HATEOAS API with minimal reprogramming of existing applications, then modernize the applications over time with minimal disruption to users.

At HarrisData we found the modern HATEOAS approach delivers excellent results. In the process of upgrading our Payroll application product we upgraded the application technology in parallel. We created a combination of API, HTML5 touch / speak application browser, and an ensemble of application servers to support typical activities such as search, query, transaction, import, metadata / security, work flow escalation, and reporting. The API combines links with metadata to describe all activities in the application. The application browser navigates links and interprets response metadata into displayed information and new links. Each specialty server handles a particular type of task as fed by the API, accessing files as directed by the metadata. This technology does not depend on payroll calculations or the file structure. It is available to support the full range of ERP and CRM applications we provide – or any extensions or supporting applications created by our customers. The applications do not need to be rewritten from their legacy form, it is enough to simply call them from the specialty servers supported by application specific metadata. Rewriting is only necessary when new requirements obsolete the legacy code.

• Home
• Software
• Support
• User Conference
• Blog
• About
• Contact Us

Address:

• 13555 Bishop's Court
• Suite 300
• Brookfield, WI 53005

Telephone:

• Company 800: (800)-225-0585
• Company Local: (262)-784-9099
• Sales: (262)-754-2810
• Fax: (262)-784-5994