Draft: August 1, 1994
W. David Wimberly
This is a short paper intended to communicate basic concepts and principles related to TARGET, the University's integrated electronic transaction processing facility. It is directed toward anyone desiring additional information about TARGET and specifically those seeking an understanding of why TARGET processing functions operate the way they do. It takes a broad perspective and provides the rationale for the overall design of TARGET processing. In addition, it explains the specific approaches taken to implement TARGET processing in LEAVE and GJIM. It is not intended as an independent reference regarding TARGET, but must be used in conjunction with application documentation and other reference materials such as the TARGET Proposal, the paper "TARGET - Integrated Electronic Transactions" presented at CAUCUS '94, and the TARGET Functional Specifications.
Note: The term change is used here to refer to any alteration of data that is needed within the information system. This may mean the creation of new information (the Add action), the modification of existing information (the Update action), or the deletion of information (the Delete action). Such changes are often discussed in terms of adding, changing, or deleting records on the data base. TARGET transactions are always requests to perform some change.
Electronic transactions save everyone time and effort since they are more efficient to process and easier to locate than paper documents. Prior to TARGET, applications were developed in a traditional manner using online maintenance functions: existing data was presented, the operator typed over fields he desired to change, the program edited the data, and if everything was valid the data base was updated in real time. In some situations, this access was restricted to appropriate subsets of data using value based security. However, many changes require approval by numerous individuals and this approval cannot be obtained using this model. Historically, the method for effecting these changes was to provide a central data entry operator with a form which has been appropriately authorized via the proper signatures. The form must be initiated, traverse the campus receiving the proper signatures, and end up in the central office responsible for the application so that the data can be entered and the update effected. These were time consuming and labor intensive steps. More importantly, the data on the form may be unacceptable to the information system since it had not been subjected to the stringent validations enforced at the point of data entry.
With TARGET, paper forms are eliminated and information system changes are captured and edited at their point of origin (or as close as possible to that point), yielding tremendous cost and time savings.
With TARGET, a change is initiated within the application in the same manner as traditional maintenance -- even though there are separate approvals required before the change can be effected. The screen used to enter the change appears the same as any other maintenance screen: new fields may be entered or existing values changed and subsequent data validations are performed on that input. However, TARGET functions provide before and after images for each modifiable field. The before image is non-display until a change has been made. Once the user changes a modifiable field, the corresponding before image of the field is displayed with user selectable attributes (the color as well reverse video or underline settings may be chosen). This makes it very easy to see what is being changed. Once the initiator commits the request for the change by pressing PF10, the system confirms the creation of the TARGET transaction identifying the change via the message line ("Txn created for ..."). Behind the scenes, the appropriate reviewers for the transaction are established based upon predefined rules for that function in conjunction with the contents of the data being operated on, and the transaction is placed in the state of pending approval.
Note: Maintenance screens used for TARGET and non-TARGET functions are not only made up of modifiable fields where changes may be keyed, but also include protected fields used to display current information. Any given screen may have more or less of either type of field. In this manner, a screen normally used to perform some maintenance function may also be very useful for inquiry purposes. For example, the xxTP functions of GJIM show mostly document information in conjunction with the TARGET change, which is merely a change of status for the document.
Yes, TARGET functions automatically access and present information on pending transactions whenever the entity 1 affected by the transaction is referenced. This is done to ensure that the user is aware and has knowledge of pending changes, since this information could be beneficial to anyone inquiring into the information system. In addition to displaying the before and after images of the modified fields, a transaction status line appears which shows that a TARGET transaction is being displayed. This line identifies the requestor of the transaction, the date it was requested, the existence of any transaction comments, and the transaction status (P for pending transactions). This transaction status line overlays a portion of the delimiter line used to separate the banner of an NSM screen from the body of the screen. In addition, PF11 (Optns) becomes available when viewing a TARGET transaction. Via this key the operator may view the transaction reviewers' activity, view existing comments, or create a transaction comment.
When a TARGET processing function is used to reference an entity for which there is no pending change, nor has a transaction been explicitly selected (as explained below), data about the entity as it currently exists within the information system is displayed. No TARGET transaction is involved in such an inquiry, and information about the entity is reported as it exists on the data base. The transaction identification line is not displayed nor is the PF11 (Optns) key available since no TARGET transaction is involved in the inquiry. In this situation, the TARGET function operates the same as any non-TARGET function.
Yes, there may be numerous changes made to the same entity. However, TARGET functions permit only one pending change per entity. If a second change were permitted to be initiated while another change was pending, its creation and validation would have to be predicated upon the first change being accepted and approved before the second change. Addressing the processing associated with such a situation would add greatly to the complexity of the system. Therefore, the system only permits a change to be initiated if there is no currently pending change for the same entity.
Once a pending or proposed change receives final approval it becomes effected and the information system is updated to reflect that change. There may be several effected changes for the same data base entity, each constituting a separate TARGET transaction. In addition to pending and effectedtransactions, there may be rejected and withdrawn transactions. A single entity may have any number of these types of TARGET transactions (other than pending).
To view information about non-pending transactions, of which there could be many, you must first select a specific transaction. This selection may be accomplished using a list function that displays the desired TARGET transaction. LTRS (List Transactions by Requestor, Status and date) is one such function that is present in all TARGET applications. TARGET applications also provide additional list functions that display the TARGET transactions for the specific entity operated on by the TARGET function. Given the selection of a transaction 2 from any one of these lists, the TARGET processing command will directly access that TARGET transaction and display it complete with the transaction identification line and the availability of the PF11 Optns. The change requested by the transaction is also displayed where the modifiable fields normally exist and the existing data base values (when different) are displayed in the before 3 image fields.
This requirement to select non-pending transactions in order to view them may seem inconvenient. However, it should be recognized that the current real data is always displayed via the TARGET process along with any currently pending transaction. This current information is what is needed to make business decisions. Normally, information about effected, rejected, or withdrawn TARGET transactions is of little importance other than as an audit trail of past activity. An exception is the need for a requestor of a rejected TARGET transaction to read the comments that were entered by the reviewer at the time of rejection. This and any other auditing of past transactions is provided via the explicit selection of the desired transaction to be examined.
Leave's TARGET implementation is different for each of its two TARGET functions.
The creation and manipulation of GJIM documents is very complex due to their line orientation and the number of lines permitted. The processing requirements to support these maintenance functions were such that there was little room left to incorporate TARGET processing features on top of these other facilities. In addition, there is no need for the before image display, because once a document is submitted for approval it can no longer be changed. (If implemented in a pure TARGET sense, GJIM documents would have been like LEAVE's OTA: always a request to add a document.) For these reasons, and the sake of data entry flexibility and programming simplicity, the maintenance of documents was separated from the approval of documents, and corresponding xxM (maintenance) and xxTP (TARGET processing) functions were created.
Note: The terms document and transactionare used in a very precise manner since there is a significant difference between the meaning of the two words in GJIM. Document refers to the entity created by the user with the xxM function. It represents all the details necessary to describe the desired adjustment that is being sought within the GL system. Transaction, or TARGET transaction, refers to the request for a change to the document's status and how that request was acted upon. Information about the TARGET transactions is only available through the xxTP, TARGET Processing, functions. However, the xxTP functions also provide facilities for viewing entire GJIM documents. As such, they are on the main menu and users are encouraged to use those functions over xxMs unless they need to perform maintenance on documents.
To provide for the necessary management and control of documents, a document status was created. 5 This document status is in some cases automatically changed by the system to reflect the user's request for approval or to reflect other actions taken on that request. Documents are created with a status of open. Only open documents can be updated by the xxM maintenance functions. Once completely built and visually inspected for accuracy, documents are submitted (action S) for approval using xxTP, which is the TARGET processing function for GJIM. At this point, several unique special processes have been incorporated to manage GJIM documents.
The GJIM variances to normal TARGET processing noted above were incorporated to address specific problems or to simplify processing for the user. However, learning this specialized implementation is difficult without a basic understanding of normal TARGET processing. Once familiar with basic TARGET concepts, it is much easier to understand GJIM, since it really does fit the model -- it just adds a few twists of its own.