A Electronic Signatures
This appendix contains these topics:
A.1 Overview
Electronic signature is a regulatory requirement of the Food and Drug Agency (CFR21 Part 11). This regulation states that transaction history logs must be maintained, and database transactions must be authorized and documented at the time of the database transaction. An electronic signature is required for every database transaction that is encompassed by the regulation.
The Database Audit Manager (DBAM) incorporates user configurable database transaction logging, credential verification, and the mechanisms necessary to support documentation of transactions thereby assisting JD Edwards World customers with compliance.
In Release A9.1, electronic signature functionality has been implemented into high priority programs selected based on customer input. This document can be used to implement this functionality in other World programs or custom programs.
JD Edwards World does not provide customer support for programs you customize, including those in which you implement this functionality.
A.2 Definitions
Electronic signature is the process of verifying the credentials, or authenticity, of the user performing or authorizing the record add, change, or delete, at the time of the database transaction, and including that authorization with the transaction in the transaction history log.
Signatures applied to single record updates are referred to as record level signatures. User verification is performed for each and every database transaction. However, to eliminate the continual prompting during transaction processes, subfile programs for example, it is permitted that one signature be applied to the transaction block. Signatures applied to multiple record updates are referred to as transaction level signatures.
A.3 Implementation
DBAM utilizes database trigger technology for recording transactions and implementing user credential authentication at the time of the database transaction.
A.4 Two Levels of Signatures
A.4.1 Record Level Authorizations
Record level authorizations are implemented by database triggers configured *Before transactions are applied to the database. If user identity is not validated (authorization received), the trigger program will cancel the database action. An I/O error is returned to the application program. The application program must respond to that error and convey it to the user. If authorization is received, the transaction is processed normally.
A.4.2 Transaction Level Authorizations
Transaction level authorizations are implemented by database triggers configured *After the transactions have been applied to the database. Application programs determine the boundaries of the transaction, establish the authorization point, obtain the electronic signature, perform the database transactions, and then release the signature.
The application invokes and responds to the server accordingly. If user identity is not validated (authorization received), the program does not process the transactions and conveys the error to the user.
If authorization is received, the transactions are processed. The trigger programs apply the signature to the transactions as they are performed. Following completion of the transactions, the authentication server is called again to release the signature.
Figure A-2 Transaction Leel Authorizations
Description of "Figure A-2 Transaction Leel Authorizations"
A.5 Signature Servers
DBAM handles user authentication when configured at the record level. The DBAM trigger programs invoke the record level user authentication server. For transaction processing applications, there are two transaction level authentication servers you can use. These two transaction level servers are discussed below.
A.5.1 P98208 Transaction Level Authentication Server
If your application falls under the umbrella of CFR21 regulations, use the P98208 DBAM transaction level authentication server. This server verifies that electronic signature is enabled on the primary transaction file before prompting for user authentication.
Note:
If a DBAM audit is not configured on the primary database file, no prompting for signature will occur.| # |
Parameter | Description |
|---|---|---|
| 1. | ##PGM | The application program calling the server. If you are using the program status data structure you can load ##PROG to this parameter. Otherwise, use the literal name of your program as in the example below. |
| 2. | ##DBFN | The primary database you are updating for this transaction set. |
| 3. | ##DBFL | The library name of the primary file. You can use *LIBL for this parameter or if using a file information data structure, the actual file/library opened can be obtain from there:
|
| 4. | ##DBFA | The transaction type: *ADD/*CHG/*DLT. If you are processing all transaction types within a subfile, use *CHG for the transaction type. |
A.5.2 P00CKPWD Transaction Level Authentication Server (External)
The P00CKPWD server is external from DBAM. It is not dependent upon a DBAM configuration being set up before prompting occurs. It also has these features:
-
Backwards compatible to legacy implementations
-
DreamWriter ProcOpts control default behavior
-
Optional parameters control behavior at runtime
-
Can establish a DBAM-compatible transaction level signature
| # |
Parameter | Description |
|---|---|---|
| 1. | ReturnCode | Char( 1 ) - User validation state (Required Parm) |
| '1' | Users credentials verified. | |
| '0' | Users credentials not verified. |
| # |
Parameter | Description |
|---|---|---|
| 1. | Function | Char( 4 ) |
| *GET | Validate and establish an eSignature | |
| *CLR | Clear the current eSignature | |
| 3. | UserId | Char( 10 ) |
| *CURRENT | Locks userid prompt to current user (job) | |
| *ANYUSER | Opens userid prompt for any userid | |
| *PROCOPT | Uses ProcOpt value from P00CkPwd/ZJDE0001 | |
| 4. | eSig | Char( 8 ) |
| *YES | Establishes an eSignature upon validation | |
| *NO | Does not establish an eSignature | |
| *PROCOPT | Uses ProcOpt value from P00CkPwd/Zjde0001 | |
| 5. | PgmName | Char( 10 ) |
| <Name> | Name of updating program to sign eSignature | |
| 6. | eExp | Char( 40 ) |
| <Text> | 40 char description to add to eSignature |
Note:
When enabling P00CKPWD for electronic signatures, the program invoking it must be changed to call the server again to release the signature when the transaction is completed.A.6 Application Program Code Samples
Two application program examples are included here. A single record update program impacted by record level signatures, and a subfile transaction processor program that implements transaction level signatures. The single record update program P4108 uses the same file server as the transaction processor P41080. Code segments will vary program to program even if you are handling the file I/O in your program. Programs vary in usage of subroutine S005 or S010 for updating database files.
A.6.1 P4108 - Single record update
This program uses a file server for database I/O. It checks the return code from the server to determine if the database action was successful. If not, it sets on an error indicator. In this program, two more lines were added to set on additional error indicators and set up the error message. Later in the code, it checks if an error occurred and the screen and error are redisplayed to the user, otherwise, the display fields are cleared for the next transaction.
CSR CALL 'XF4108 ' C* ---- --------- CSR PARM PS@@1 CSR PARM I4108 C* CSR SELEC CSR @@IOR WHEQ 'ERR' CSR MOVE *ON *IN99 CSR SETON 93 40 CSR MOVE '1' @MK,1 CSR ENDSL
A.6.2 P41080 - Transaction processor
This is a subfile transaction processor. Since it falls under CFR21 regulations, it now includes the copy members for invoking the DBAM transaction authentication server. At the appropriate place in the program, before processing the subfile, the program calls the DBAM authentication server. (See server description above for parameter descriptions.)
* -------------------------------------------------------------- * Check for and acquire electronic transaction eSignature... * CSR MOVEL'P41080' ##PGM P CSR MOVEL'F4108' ##DBFN P CSR MOVEL'*LIBL' ##DBFL P CSR MOVEL'*CHG' ##DBFA P CSR EXSR C98208 * ---- ------
Upon returning from the transaction signature server check the primary error indicator (*In93). If an error occurred, the program issues an error, exits the subroutine, and displays the error to the user. No transactions are processed.
CSR *IN93 IFEQ '1' CSR SETON 9340 CSR MOVE '1' @MK,1 CSR GOTO END005 * ---- ------ CSR ENDIF * --------------------------------------------------------------
Note:
If a DBAM audit is not configured on the primary database file, no prompting for signature will occur. Control returns to your application and the transactions are processed.After all the transactions have been processed, and before exiting the subroutine, the authentication server is called again to release the signature.
* -------------------------------------------------------------- * Release the electronic transaction signature... * C EXSR C98209 * ---- ------ * --------------------------------------------------------------
The transaction process is now complete. Here is the copy module code to include the required subroutines for invoking the transaction level authentication server. These two modules must be included for transaction level signatures.
**************************************************************** * Copy module to acquire a transaction eSignature. * C/COPY JDECPY,C98208 ****************************************************************
* Copy module to release a transaction eSignature. * C/COPY JDECPY,C98209 ****************************************************************
A.6.3 Example of Single Record Update
When the program updates the database file, it includes an error indicator on the I/O operation. After the file I/O, it checks for an error. In an error was received, it signals the condition to the user. Otherwise, it continues as usual and resets for the next transaction.
C**************************************************************** C* SUBROUTINE S005 - Scrub Input C* ------------------------------ C* CSR S005 BEGSR C* ---- ----- C* Data validation code here C* Update file. Monitor for I/O error. C* CSR SELEC CSR *IN21 WHEQ '1' CSR WRITEIFILE 93 C* CSR *IN22 WHEQ '1' CSR UPDATIFILE 93 C* CSR *IN23 WHEQ '1' CSR DELETIFILE 93 CSR ENDSL C* C* Database I/O error. Maintain screen and issue error to user. C* CSR *IN93 IFEQ '1' CSR MOVE '1' *INxx CSR MOVE '1' @MK,x CSR ELSE C* C* Clear data fields for next transaction. C* CSR MOVE #FCLR @@AID CSR EXSR S001 C* ---- ---- CSR ENDIF C*--------------------------------------------------------------- CSR END005 ENDSR C****************************************************************
In the above example, the RPG error indicator and error message array position are dependent upon your application requirements.
A.6.4 Transaction Level Interfaces - Copy Modules
Included here are copies of the Copy Modules that must be included in transaction processor applications that are using the DBAM transaction level authentication server.
C98209L - Copy module to invoke the transaction eSignature. **************************************************************** * SubRoutine C98208 - Check for and acquire an eSignature... * -------------------------------------------------------------- C C98208 Begsr * ------ ----- C *Like Define PsPgm ##Pgm C *Like Define PsDbfn ##Dbfn C *Like Define PsDbfl ##Dbfl C *Like Define PsDbfa ##Dbfa C Call 'P98208' * ---- ------ C Parm '*ACQ' PsFunc 4 C Parm PsRtn 1 C Parm ##Pgm PsPgm 10 C Parm ##Dbfl PSDbfl 10 C Parm ##Dbfn PSDbfn 10 C Parm ##Dbfa PSDbfa 4 * Check return status from eSignature server... C Select * Return code of *Zero means we have an authorization... C PsRtn Wheneq '0' C Move '1' ##eSig 1 * Return codes less than 4 indicate that eSignature is not * configured or not turned on... C PsRtn Whenlt '4' C Move '0' ##eSig 1 * Return codes greater than 3 are errors... C PsRtn Whengt '3' C Move '1' *In93 C Endsl C E98208 Endsr C**************************************************************** C98209L - Copy module to release the transaction eSignature. **************************************************************** * SubRoutine C98209 - Release transaction eSignature... * -------------------------------------------------------------- C C98209 Begsr * ------ ----- C ##eSig Ifeq '1' C Call 'P98208' * ---- ------ C Parm '*END' PsFunc 4 C Parm PsRtn 1 C Move '0' ##eSig C Endif C E98209 Endsr ****************************************************************
C98208 - Copy module to invoke the transaction eSignature. **************************************************************** * SubRoutine C98208 - Check for and acquire an eSignature... * -------------------------------------------------------------- * CSR C98208 BEGSR * ------ ----- * CSR *LIKE DEFN PSPGM ##PGM CSR *LIKE DEFN PSDBFN ##DBFN CSR *LIKE DEFN PSDBFL ##DBFL CSR *LIKE DEFN PSDBFA ##DBFA * CSR CALL 'P98208' * ---- ------ CSR PARM '*ACQ' PSFUNC 4 CSR PARM PSRTN 1 CSR PARM ##PGM PSPGM 10 CSR PARM ##DBFL PSDBFL 10 CSR PARM ##DBFN PSDBFN 10 CSR PARM ##DBFA PSDBFA 4 * * Check return status from eSignature server... * CSR SELEC * * Return code of *Zero means we have an authorization... * CSR PSRTN WHEQ '0' CSR MOVE '1' ##ESIG 1 * * Return codes less than 4 indicate that eSignature is not * configured or not turned on... * CSR PSRTN WHLT '4' CSR MOVE '0' ##ESIG * * Return codes greater than 3 are errors... * CSR PSRTN WHGT '3' CSR MOVE '1' *IN93 CSR MOVE '0' ##ESIG CSR ENDSL * CSR ENDSR **************************************************************** C98209 - Copy module to release the transaction eSignature. **************************************************************** * SubRoutine C98209 - Release transaction eSignature... * -------------------------------------------------------------- * CSR C98209 BEGSR * ------ ----- * CSR ##ESIG IFEQ '1' CSR CALL 'P98208' * ---- ------ CSR PARM '*END' PSFUNC 4 CSR PARM PSRTN 1 * CSR MOVE '0' ##ESIG CSR ENDIF * CSR ENDSR ****************************************************************