Revision 2: March 12, 1992
W. David Wimberly
University of Arkansas, Fayetteville
TARGET (Transaction Approval & Review Gateway via
Electronic Transmission) is intended to provide state of the art
electronic forms processing capabilities for the University of Arkansas.
It provides direct transaction data entry into an application at the
point of data origin.
These remotely entered transactions are held in a pending state until
appropriate reviews and approvals are obtained.
Once final approval has been electronically obtained the transaction
is posted to the data base within the University's administrative
Note: A transaction as used within the TARGET system
represents a request for a specific and independent activity to
be performed within an administrative system.
This is normally to add, delete or update information, but may take
various forms as dictated by the application implementing the activity.
The TARGET system itself only provides a framework for this
The administrative applications employing TARGET must be
designed and written with the intent of using this framework
and in accordance with specific requirements.
The University is fortunate to be at the initial stage of
developing new applications in the human resource, budgeting, purchasing,
and financial areas which will be able to take advantage of
The TARGET components assume that applications that
use these facilities will be developed using the Natural
Secured Menus Architecture (NSM) and the internally
developed Program Generator.
This Proposal has been prepared to solicit support
and approval for the
Transaction Approval & Review Gateway via Electronic Transmission
This document describes the features and capabilities of the
It also identifies new responsibilities and policy issues which
must be addressed by the university administration for
the success of such a system.
This document should
serve as a basis for evaluating the proposed
system and, if necessary, identifying
enhancements or alternate concepts that may be desired.
The need and demand for electronic forms to replace paper
has existed for a number of years.
Many parties have moved ahead with development of screens,
mimicing paper forms, where data could be entered.
After entry, these screen images are printed and routed around
campus as paper forms.
This process may have enhanced production of the paper forms
through automated word processing, but did nothing to speed
the processing of data into the functional application,
verify the integrity of the data entered,
or eliminate the duplicate keying of information by the
Some institutions have extended this approach to
include the electronic routing of forms and the recording
of electronic approvals.
With this approach, real advantages begin to appear.
The concept employed by TARGET is a complete
integration of the data capture, routing, and approval process
with the administrative application for which the data is
This proposal is a general presentation of this concept
but addresses specific issues related to its implementation.
It is the result of significant planning, research, prototyping,
and discussions which began in the summer of 1991.
The objectives of the TARGET system can be summarized as follows:
- Provide a core architecture to facilitate the implementation
of applications which utilize a distributed data entry
function combined with centralized reviews and approvals
of those activities in a secure and auditable manner.
- Employ this architecture in a generic manner such that it can
be implemented in various administrative applications.
This will result in:
- The consistent use and deployment of this technology
across the University community resulting in reduced training and
- Centralized management of control
tables and all transactions.
- Cost savings in the development process due
to the shared use of the design, program code and
- Meet the increasing
demand for electronic forms processing with a system where:
- Data will be completely validated at the point of entry.
- Forms will not have to be printed in order to be processed.
- Transaction information will only have to be keyed once.
- The original transaction will become an
integrated part of the central administrative information
system and the University data base.
- Implement these facilities using the Natural programming
language within the applications
development framework of the NSM Architecture, both of which are
proven and established at the University.
TARGET offers numerous special processing features.
Many of these are the result of the total integration of the
original transaction entry and review processing with the base
application which manages the resulting data.
Some of the features, facilities, and resulting benefits provided by
- TARGET will replace the use of paper forms including the need to
copy, file, mail, and process these forms.
Electronic transactions will replace forms, but will contain the
same information for
directing actions and effecting changes within the administrative
This will result in
cost savings in the areas of copying,
internal mail distribution, personnel time, and storage.
- Electronic transactions will be available for review and approval
immediately online, eliminating the time lag associated with handling
The benefits of more timely processing of administrative
transactions are intangible and difficult to quantify,
but are obviously highly desirable.
- The basic transaction data will be entered at the point of
origin and will
not be re-keyed by the
administrative office responsible for the application.
This will reduce the data entry work load within either the
or within Computing Services keypunch area.
Within the originating offices,
the data entry function replaces the
manual entry or typing of the same information onto forms.
The screens used to enter data are a part of the
primary application and
employ strict edits and validations, which results in
more accurate, higher quality information.
This improvement in the integrity of the data is one of the primary
benefits of TARGET.
Fewer errors will result in fewer corrections and reduce the number
of times and the number of people that have to handle an item.
This is expected to result in
significant improvements in office efficiency and productivity.
- The ability to track and review the status of transactions
will be provided.
Pending, completed, and rejected transactions will be maintained in a
data base and be available online for review for a period of time
as defined for each transaction.
Transactions may be listed by requestor and transaction status,
by reviewer (pending transactions only),
and by data base entity affected (this is dependent on, and varies by,
This simple and rapid access to, and availability of, data is
expected to reduce the number of inquiries made by departments
to the central offices.
This will save time both within the departments and within the office
previously required to research those questions.
- Security definitions and the review process have been designed
to operate based upon a desk concept rather than an
These position based security and transaction routing
definitions provide a significant advantage
over individual based security
in the administration area.
When security is tied to an individual and that person is reassigned
within the University, all their security (access
privileges) and review (transaction routing) definitions
must be reviewed and updated.
Position based security is just that, all security definitions are
tied to a desk associated with a
job so that transfers and personnel changes do not
necessitate mass changes within the system.
Instead, the new person is assigned to the old desk and immediately
given the appropriate access and authority.
Desks are associated with departments who control the assignment
of those desks to the employees of the departmnet.
This scheme also
allows one definition to service multiple individuals since
several people may be authorized to work the same desk.
- The association of a transaction with the
desks that are to be
review responsibility is the heart of the electronic approval
The TARGET system uses one central routine to make this determination
for all transactions based upon
the type of transaction and the data being acted upon within the
transaction (referred to as the review criteria).
This approach provides maximum control over the process while
allowing flexibility since the maintenance
and enhancement of this function is localized to one routine.
- An optional criteria for the establishment
of the desks responsible for reviewing
a transaction is the dollar value associated with the
Different desks may be defined based upon this dollar
This allows assigning review responsibility for some transactions
based upon the spending authority of the desk.
Note: The dollar value is not the primary criteria which is used
to determine which desk should review a transaction.
Those criteria are unique and specific to each type of transaction and
are described generically within TARGET as review criteria.
Another aspect of the establishment of the desks required to
review a transaction is exception handling.
If, using tables established for this purpose,
the system cannot determine the desks of the reviewers based upon
the transaction data,
a default set of desks may optionally be defined to be established.
This will ensure that a transaction is not prevented from being
entered due to missing control information.
- TARGET allows from 1 to 10 desks to be established
for the review of each transaction, each assigned a review level.
All approvals must be obtained
at a lower level prior to the transaction
being presented for review at a higher level.
This will permit multiple individuals to review the same transaction
at the same time while also holding a transaction back from review at
higher levels until appropriate.
Either or both options may be employed selectively.
Note: The term presented is used to mean that a
transaction will either appear on a transaction
list for review or will automatically
be retrieved for review according to its time of entry, based upon
the identity of the reviewer and the desk they are working.
- Several features have been designed into the system to ensure that
the review process is simple and effective.
- Transactions are presented in the chronological order that they
Each may be approved, rejected or bypassed and the next transaction
is retrieved automatically for processing.
- To aid in the identification of what is being changed by an
update transaction (a transaction where new data overlays
the screen will be designed with both the old and the new values present.
The old field values are displayed
only when they differ from the
They may also be
displayed using special features such as reverse video or color,
if that capability is
supported by the terminal or terminal emulation software.
This will allow identification of a field whose old value was blank.
- A summary list function will be available to identify
how many transactions of each type are pending an individual's review.
- The edits and validations performed on the original transaction
are invoked each time the transaction is reviewed and at the time of
These consistent checks will help guarantee the integrity of the
data within the University data base.
Technically , these edits are performed by the same program each
time, which minimizes code redundancy,
the opportunity for programmer error,
and the program maintenance effort when changes are required.
- A complete audit trail is maintained for
all transactions by
recording the date, time, and individual performing
any action on the transaction.
This includes the original entry, all
review actions performed, and the final disposition.
This history of the transaction and review process will be
available online via a pop-up window displayed by a centralized
Thus, complete document tracking and status checking information
will be available to the originator, the reviewers, and all others
with access rights to the transaction.
- Transactions may have up to 12 comments associated with them.
These short yellow stickies may be entered or viewed by
anyone associated with the entry or review process.
In this manner explanations and references outside the actual
transaction may be communicated between the originator, the
reviewers, and the central administrative office responsible
for the application.
A comment will be required whenever a transaction is rejected
during the review process.
Comments, similar to the transaction history, will be available
via a pop-up window managed by a centralized routine.
Rejected transactions will require entry of a rejection code
and a comment.
In addition, a notice to the transaction originator
is posted to a central data base file.
These and other notices will be
checked whenever a user signs on to Natural.
The user is informed at that time of outstanding notices
and each is displayed for their review and subsequent action.
- The TARGET system is built on the philosophy that a desk
is identified to review selected transactions as
determined by the central administration.
The individual or individuals
associated with that desk
should be the ones that normally perform that
function, and it must be
their responsibility to fulfill that role.
TARGET will establish the appropriate transactions with that
desk's ID for review expecting that review to occur.
However, there will be times when all reviewers authorized to work
a desk are absent and
someone else must be designated to act on behalf of at least one of
In this circumstance the TARGET system provides a proxy
Other individuals may be predefined, for a period of time, to
act as a proxy for a desk for specific applications.
The system will maintain as part of the audit trail when and who was
acting as a proxy when action was taken on a transaction.
The establishment of proxies will be allowed by any individual
directly authorized to work a desk,
but that authority must also be granted to a system
administrator to be used in situations involving sickness or
other unexpected absences.
- Existing transactions, either completed or canceled, may
be copied and used as the basis for entering a new transaction.
The original transaction must first be selected for viewing and
then the keys for the new transaction and the copy action
This option may be used to enter several transactions that are
nearly identical or to retrieve a canceled transaction so that
it can be modified and resubmitted.
There may be situations where this feature
cannot be provided due to the processing constraints of specific
- All transactions cannot be maintained online indefinitly.
The TARGET system provides facilities to archive, report
to hardcopy or microfiche, and
delete completed or cancelled transactions.
Criteria for determining how long transactions are to be
maintained online is based upon the transaction type
and its status.
In this manner varying needs of different systems can be accommodated
while performing this critical function in a centralized,
coordinated and timely manner.
Reports will be available to print all transactions of a selected
type which occurred over a selected time period.
This facility should assist in problem analysis and in
meeting audit requirements.
- Transaction data is stored in a generic format on the central
This means that individual fields such a salary, grade, or department
are not identified as such.
Instead, the applications that process the specific transactions
redefine the generic data area according to their specific
It can be expected that the transaction contents and generic format
may change over time for a transaction.
Therefore the system retains a transaction version with
each transaction so that the format and processing requirements of the
transaction will always be known.
This will assist in the transition from new to old during periods
- The application functions used to view data will detect if there is
a transaction pending for a data entity and will display the
pending transaction information.
It will also identify the originator and the
date and time the transaction
This means that the latest information will always be available, although
the user must be aware that the transaction is still
pending and has not received final approval.
- The system has been designed to be as efficient as possible,
attempting to minimize the data base I/O required to support the
For example, in normal cases only two data base calls will be required
to establish the reviewers for a new transaction.
This will help ensure that system response times are kept as short
- The TARGET administrator may request a list of transactions
that have been pending review longer than considered normal.
The number of days a transaction may be pending before being
reported may be customized via online definitions for each
With this facility, the system can be monitored to ensure that
transactions are not lost within the system.
- An e-mail interface will also be available where short messages
regarding a transaction can be sent to another user.
The subject of the e-mail will automatically be filled in with
information identifying the transaction.
This facility will be restricted to users who have a primary
e-mail address identifyed within the Computing Services' directory
of user IDs.
The TARGET system assumes a complete integration of the distributed
data entry function and its resulting electronic
approval with the application
where the data is processed.
In this primary area, TARGET provides a framework and
model for building application programs that incorporate electronic
transaction processing features.
This requires the application to be designed with the
intent of using TARGET and that
application programs are written
according to standards and models provided by TARGET.
Due to this tight integration,
TARGET cannot be easily overlaid onto existing applications.
In another area,
TARGET provides a set of core support functions which are used
independently by all TARGET applications.
The establishment of the
desks that will be responsible for the
review of a transaction is one
example of a function performed by one of these independent routines.
There are many others.
A third area is the TARGET administration system.
This is an application that provides operational and management support
Functions provided by this application include
maintenance of control tables and transaction routing tables;
routines to archive, print, and purge transactions;
identification of transactions which have not been reviewed within
a reasonable period;
and the ability to establish proxies for others.
Note: Since each application and its requirements are unique, TARGET is
described using generic references to application components such as
data base entities, data base keys (data values which uniquely identify
a data entity), and transactions.
Such references will be found throughout TARGET documentation.
The primary processes for TARGET can be divided into two
areas, those that are performed for a transaction within an application
and those which support that operation via the TARGET administration
Each of these is discussed briefly.
The transaction processor is the key component of a
TARGET application and is
responsible for performing all of the following functions:
Several TARGET subprograms assist in this process by
establishing the appropriate desks for review of the transaction,
displaying and allowing entry of comments to be carried with the
displaying a historical log of activities performed on the transaction,
generating a notice to the requestor of the transaction if it is
and verifying the proxy authority of a user.
- Displaying existing application data and outstanding
pending transactions when present.
- Processing the original input data for a transaction
complete with data edits,
the enforcement of application security, and saving the transaction
for later review, posting, and audit.
- Presenting pending
transactions for review and recording the results of
the review (approval or rejection).
- After all approvals have been obtained, posting the transaction
to the appropriate application data base.
The TARGET administration application provides facilities for
managing the data required to drive TARGET systems.
This includes maintenance of transaction control information,
routing information (via
review groups, criteria types, and review criteria), and proxies.
Facilities are also provided to report transactions which have
been pending too long and to
archive, print, and purge transactions based upon defined
The following points are included to clearly state
operational characteristics or issues which may have only
been implied or not stated to this point.
- TARGET provides no facility for priority coding a transaction
so that its processing might be expedited.
If a transaction needs to be "walked-through" the system,
the originator will
need to telephone the reviewer(s), identify the transaction,
and request that immediate action be taken on the transaction.
The reviewer can then directly select that transaction from a list
and process it.
It is expected that the need for this type of activity will be
significantly reduced due to the speed in which the
electronic entry and
review can be accomplished.
- Changes made to the review criteria will
affect transactions entered after that point.
Transactions entered previously are established with the
reviewers and review levels that were in effect at the time
No facilities have been planned or provided for altering the
(who is to review a transaction at what level)
that is established for a transaction.
- A reviewer will not be allowed to
modify any information within a transaction.
If a reviewer determines that a transaction has not been entered
correctly or is unacceptable for any reason, the reviewer must
reject the transaction.
The originator may then reinitiate the transaction in a corrected form.
This can be easily accomplished by retrieving the rejected
transaction, copying that information to serve as the basis of a
making additional changes and corrections,
and then submitting the new transaction for review.
Note: I always wondered if this would really fly.
It appears that there will be some, if not many, cases where
a transaction is at least supplemented, if not directly
modified, during the review process.
- Multiple review criteria may be used to establish the reviewers
for a single transaction.
In this situation the review list resulting from each criteria
is always merged with duplicate reviewers eliminated at their
If the result of the merge process is more than 10 reviewers,
reviewers at the lowest levels will be eliminated.
- If the requestor is also established as a reviewer, based upon the
review criteria, that review status is automatically set to approved.
- Transactions which require special forms, paper work or other
backup materials in the central administrative office
can also be processed through TARGET.
In this situation, the central office or the recipient of the paper
work must be defined as a reviewer of the transaction.
Special procedures must be employed by that reviewer to ensure that
such transactions are not approved until the necessary documentation
has physically been received.
A reviewer may indicate this situation with a special status code.
status may be placed on transactions for other reasons and
will be available on transaction lists.
A comment should be added to a transaction that it is being held.
- The system will not permit
multiple transactions of the same type to be
pending for the same data base entity at the same time.
For example, two address changes for the same
individual pending at the same time.
One change would logically overlay the other at final approval and
is therefore not allowed.
Transactions are not applied to the data base until they reach final
Validations associated with a transaction may involve data base
checks which are affected by the completion of other transactions.
Therefore it is possible that a transaction will be valid at the
time of original entry but may no longer be valid when it is being
Such transactions cannot be approved.
They must either be rejected or held until some subsequent action
would allow them to pass validation criteria
(perhaps a transfer of funds).
- Applications that use TARGET,
due to their nature of allowing distributed transaction entry,
may also need to implement security by value.
This will permit restrictions to be placed on what data is allowed to be
entered for a transaction based upon the originator.
For example, an individual in
Computing Services would only be allowed to enter
data for Computing Services and not for any other department.
- Comments are retained as they are originally entered, there are
no facilities provided to delete or alter comments.
Additional comments may be entered up to the maximum allowed.
- The transaction file will always contain the new information
being submitted for the transaction.
After a transaction has been completed, this will correspond to the
information stored on the data base, referred to in data processing
as the after image.
To determine what data existed prior to a transaction being processed,
the previous transaction completed for that data base entity/transaction
type must be retrieved.
- The new applications being developed are expected to employ
much tighter controls and more stringent online validations than
These validations will be implemented in an integrated fashion
within our total information system.
This should result in fewer needs for transaction
approval, eliminating many of the check points currently
In order for distributed transaction entry and approval to be
successful, new responsibilities must be assumed by
many offices and individuals.
Some of the specific areas where this is true include:
The full commitment of the university
will be required to support the successful implementation of TARGET.
The advantages of more timely processing,
reduction of errors, higher quality data,
increased productivity, and
greater access to information warrants this commitment.
- The university administration must develop and adopt a policy
endorsing the concept
of electronic approval of transactions and specifically the TARGET
- An office and individuals must be designated to maintain the
required routing tables (the review criteria and review groups)
and to act as the central administrator for the TARGET system.
- Campus wide, all offices must receive the appropriate training
to use the new systems that are deployed.
- The individuals designated to review pending transactions must
perform that task in a timely manner.
- Computing Services must provide adequate resources for processing,
storage, maintenance, support and enhancement of the system.
Since these applications will become integral to almost all
added attention may also need to be directed toward backup, recovery and
- Due to the wider access that will be provided to online
administrative systems, security issues must be emphasized.
Confidentiality of IDs and passwords will need added emphasis,
auditing of computer use activities must be increased, and other
policing actions instigated.
- When position based security is implemented, detail maintenance
will be required of the association of desks
In the interim, the association of desks to individuals requires
an even greater level of activity due to personnel changes.
Security issues are of greater concern when broader access
is provided to applications performing critical or financial functions.
Access to TARGET applications will be controlled by the
same means as currently used within our financial systems,
personalized IDs and private passwords.
There will only be the CICS ID/password required, unlike MSA
and some other systems which require dual sign ons.
This will be an improvement since only one ID/password
will have to be remembered
(reducing the need to write them down)
and the user is able to change their password whenever desired.
Access to applications and privileges within those applications
are based upon definitions maintained within the NSM Maintenance
This administrative function is performed directly by
individuals within the offices with data custodian responsibility.
These administrators must make the correct definitions and
so must be conscientious in performing this task, however this
is no different than with any other system.
The same situation exists with the review criteria and
groups which must be maintained by a TARGET administrator.
Consideration must be made for backup procedures and system recovery
in case of hardware crashes or other
failures which make the system unavailable.
It is anticipated that such mishaps would be rare and of a short
This is due to the high level of reliability that exists in modern
computing hardware and the use of state of the art data base
TARGET and the applications being considered for use with it
rely on ADABAS for their data base management functions.
This product is a vast improvement over VSAM, which is currently
used with our MSA systems, and OASIS for the following reasons:
- Batch and online processes can execute simultaneously.
Much of the downtime currently incurred by our online systems is due to
overruns in the batch processing window (evening hours)
or the need to immediately execute some batch process.
Either situation forces the online facilities to be shut down
while batch is running.
This is not a requirement with ADABAS (although there may be some
specific application reason that online should not be used while
a certain batch process is executed).
Additionally, the new applications will not rely on batch processing
to the same extent as current systems.
Batch will primarily be used for reporting.
- ADABAS provides superior recovery facilities in case of a disk
Along with the primary data base files, ADABAS maintains a protection
log which contains a record of all updates performed.
Regular backups are made of the data base and the
protection log is synchronized to this backup.
Given a disk failure, the affected ADABAS files are restored and
all updates to those files are reapplied from the protection log.
This process should normally require from 1 to 2 hours.
OASIS offers a similar facility, but the entire data base must be
recovered which requires many hours.
There is no such recovery facility for our VSAM data.
The most feared form of failure is a complete disaster, where
the computing center is rendered inoperable due to fire, flooding
Computing Services is actively developing a Disaster Recovery
Plan which will address the complex issues that surround this
In fact, some funding and a great deal of work has already been
performed in this area including the selection of alternate and
backup sites where processing could be performed.
The bottom line is that there will be periods when the system
will not be available and manual procedures will have to be employed.
Paper documents may have to be used to serve as a queue of input
for the online systems, once they are available.
However, except in the case of major failures or a dreaded disaster,
a little patience is all that should be required to survive those
periods when "the system is down".
The audit function should be much improved with TARGET
since all distributed transactions will be centrally located
with a complete historical log of the review process.
All transactions, complete with logs and comments, will be
available online for some predefined period of time.
Custom batch programs may also be developed to
report transaction activity.
detail reports of all transactions will be produced prior to their
archival and migration from the online environment.
More information should be available in a more convenient form
than ever before.