This chapter contains the following topics:
Section 3.1, "Understanding Auditing and Electronic Signature Setup"
Section 3.2, "Enabling Auditing and Electronic Signatures for a Pathcode"
This section discusses:
Auditing for interoperability transactions
Audit table setup.
Table Design Aid in audit mode.
Table date and time data.
Table naming conventions.
Tables associated with auditing and electronic signatures.
Electronic signature setup.
Electronic signatures for power forms and subforms.
Audit records, signature records, and globally unique identifiers (GUID).
An interoperability transaction can affect a column in a JD Edwards EnterpriseOne table that has been enabled for auditing. When this occurs, JD Edwards EnterpriseOne creates an audit record for the transaction, but the system only records a portion of the audit information, such as the audited column, before and after values, and recorded columns. The audit information will not include a GUID, application ID, workstation name, or IP address, unless you configure the interoperability model to pass this data to the audit record.
You use the Configuration Application (P9500001) to select the table that you want to audit. After selecting a table, JD Edwards EnterpriseOne launches Table Design Aid (TDA). In TDA, you select the actual columns in the table that you want to audit.
When the auditing function in JD Edwards EnterpriseOne is turned on, the system records changes, additions, and deletions to the data in these columns in an audit table (shadow table) to provide a tracking history. An audit table contains the columns used as the primary key of the original table along with the columns that you define to trigger an audit. In addition, you can select columns for recording. Recorded columns do not trigger an audit, but appear in an audit table along with the other columns that trigger an audit.
Every time a change is made to an audited column in the original table (Fxxxx), the audit table (Axxxx) records this information:
The field that was changed.
The previous value in the field.
The new value in the field.
The date and time of the change.
Any other fields in the table that were selected for auditing.
Any other fields in the table that were selected for recording.
The form, application, and version name used to make the change.
The user ID and internet protocol (IP) address of the person who made the change.
The auditing function can be turned on or off for each specific table. Even the action of turning the auditing function on and off is recorded in a table to provide a history of the audit tables.
When TDA is launched in audit mode, it displays the default columns of the table that you are auditing in read-only mode. You can drag and drop columns that you want to audit from the audited table (Fxxxx) to the audit table (Axxxx). BLOB (Binary Large Object) columns are not displayed in audit mode and cannot be audited.
All primary key columns of the audited table are automatically added to the audit table. The default audit table columns are automatically added to the audit table as well. If a default index does not exist, TDA creates one for the audit table and populates it with CFRGUID and B4ORAFTR from the default audit table columns, along with the primary key index columns.
This section describes each of these tables associated with auditing and electronic signatures:
Configuration Table (F9500001)
Reason Codes (F9500002)
Audit Header (F9500003)
Audit Detail (F9500004)
Temporary Audit (F9500005)
Signature (F9500005)
Audit (Axxxx)
Database Object Template Information (F986112)
The F9500001 table stores the configuration information that is entered using the Work with Configuration Settings form in the P9500001 application. The F9500001 table contains the object name, form or version, the event used, environment, the audit table, who to report realtime information to, number of signatures required, and the reason codes associated with the audit.
The F9500002 table stores the reason code information that is entered using the Work with Reason Codes form in the Reason Codes application (P9500002).
The F9500003 table stores the audit header information. This information includes the unique ID, user ID, user's full name, user's address book number, the workstation from where the change was made, date, time, and program ID.
The F9500004 table stores the audit detail information. This information includes the unique ID, table name, audit table name, the action used, user ID, workstation from where the change was made, date, time, and program ID.
The F9500005 table temporarily stores the audit information. Results from queries or Universal Batch Engines (UBEs) run on the client are stored in this table and used for reporting.
The F9500006 table stores the captured signature information. One F9500006 table exists per instance of JD Edwards EnterpriseOne. This table records a unique ID, the object, the form or version name, the user ID, the user's full name, their address book number, the Reason Code they choose, and their group name.
Electronic signature failures are written to the F9500006 table only after four failed authorization attempts. The authorization is recorded as a failure, and a notification is sent to the person identified in the Real Time Notification configuration, if enabled.
This table stores the audit information. When auditing is turned on for a particular table, the system creates an audit table that contains the primary keys of the audited table, audited columns, recorded columns, and these default columns:
| Data Item Name | Alias | System | Type | Size | Populated By | Value |
|---|---|---|---|---|---|---|
| CFR GUID | CFRGUID | H95 | String | 36 | Trigger |
|
| Primary Key Columns of Audited Table | N/A | N/A | N/A | N/A | JD Edwards EnterpriseOne or third-party | Primary key value |
| Before or After | B4ORAFTR | H95 | Character | 1 | Trigger |
|
| Action | CFRACTION | H95 | Character | 1 | Trigger |
|
| Audited Columns | N/A | N/A | N/A | N/A | JD Edwards EnterpriseOne or 3rd party | Data being audited |
| User ID | CFRUSER | H95 | String | 10 | JD Edwards EnterpriseOne or Trigger | UserID |
| Machine Key | CRFMKEY | H95 | String | 15 | JD Edwards EnterpriseOne or Trigger | MachineID |
| Date/Time | DATETIME | H95 | String | 26 | Trigger | Actual date/time |
| Program ID | CFRID | H95 | String | 10 | JD Edwards EnterpriseOne or Trigger | Program ID |
| Audit Type | AUDITTYPE | H95 | Character | 1 | Trigger |
|
The audit table must be in the same data source as the parent table.
Note:
If an application or business function (BSFN) runs in a transaction boundary, and the transaction gets rolled back, the audit table may not contain any changes that are rolled back. Because the Audit Header and Audit Detail tables are not included in the scope of the transaction, records written to these two tables are not rolled back.The F986112 table stores trigger templates. This table is populated by the DBTemplates.exe program. The templates in F986112 are used by the database drivers to create native database triggers.
The Audit Header (F9500003), Audit Detail (F9500004), and Signature (F9500006) tables have the date and time in two separate columns. The data is populated using native database triggers. The date consists of the year, month, and day. The time consists of the hour, minute, and second. These tables must be mapped to the same data source to ensure that they have the date and time from a central source. This data source must be a non-Julian data source.
For all audit tables, date and time are combined into a single string column. The native database trigger populates year, month, day, hour, minute, and second.
When audit table triggers are created, JDB alters the audited table by adding audit-related columns and any columns that native database triggers need in order to perform an audit trail. However, this addition changes the physical metadata for the audited table, making it different from the table's JD Edwards EnterpriseOne specification.
For JD Edwards EnterpriseOne applications and other third-party applications to function properly, the audited table is renamed. A new database view is created for that table using the original audited table name. For example, when auditing is enabled for the Address Book Master table (F0101), the audit table triggers are created on the F0101 table. JDB renames F0101 to F0101_ADT. A database view named F0101 is created for the F0101 using all the existing JD Edwards EnterpriseOne columns. The new renamed table, F0101_ADT, is altered to add all audit-related columns, and a set of native database triggers are created on F0101_ADT to send any changed records to the audit table (A0101 table). This approach enables JDB to pass audit information to the native database triggers. At the same time, access to the audited table, either through third-party software or a JD Edwards EnterpriseOne application that queries metadata, can function properly without any modification to the application.
Note:
Because audited tables add _ADT to the table name, any existing tables ending with _ADT are assumed to be audited tables. Before installing the software, check all databases for tables with _ADT and rename them.When disabling auditing for a particular table, the operation is the reverse of enabling auditing. JDB puts the table back to the stage where it was before the auditing was enabled.
You can configure interactive and batch applications to require an electronic signature approval to complete a transaction or launch a report. You can configure electronic signatures for an application only if auditing has been enabled for the same application.
The electronic signature consists of the user ID and password of the approver. When an approver enters a valid electronic signature, JD Edwards EnterpriseOne records the approver's information in the Signature table (F9500006).
JD Edwards EnterpriseOne verifies an electronic signature by checking that the user is a JD Edwards EnterpriseOne user, that the role is acceptable, and that the user ID and password are valid. If the electronic signature fails, an error is generated. After four failed attempts, the user is no longer given the opportunity to enter an electronic signature, and the attempt is logged in the F9500006 table. No progress is allowed without a valid signature.
You can use up to two roles to define those users allowed to enter electronic signature approvals for a given application. For instance, you may have a business process that calls for two electronic signatures to approve a transaction. You can assign two roles to the signature configuration: a role for the first approval and a role for the second approval. The roles can include users who have different levels of authority in the organization, such as a role that includes supervisors and another role that includes managers.
You can turn on or turn off the electronic signature function at the pathcode level. Whenever a change is made in the state of the signature function, it is recorded in the Configuration Table (F9500001).
All electronic signature approvals require a reason code. Reason codes are used to denote the reason for an electronic signature approval. When an approver enters an electronic signature, they must also select a reason code for the approval. Using the Reason Codes application (P9500002), you can create new reason codes, view current reason codes, activate or deactivate reason codes, and define default reason codes. You can define a default reason code for an application, although all reason codes are available for each application and can be easily changed.
Existing reason codes cannot be edited or deleted, but their status can be changed to either active or inactive. This action ensures that obsolete reason code descriptions are still available for older audit records. In addition, you cannot change the status of a default reason code.
You can use any of the following options when configuring electronic signatures for an application:
| Option | Description |
|---|---|
| Real Time Notification | This option informs a user or administrator when an approval fails due to an incorrect password, user ID, or permission. Four approval failures for the required signature will generate a notification message. When you configure the application for an electronic signature approval, you can specify the address book number or email address of the person to be notified. You can configure a different user to receive a notification for each application that you configure to require a signature. |
| Pre-populate Approver | This option automatically fills in the user's JD Edwards EnterpriseOne sign-in information for the first and second approver, depending on the configuration for the number of approvers. |
| Pass Through User | This option records the user's JD Edwards EnterpriseOne sign-in information when using a specified application. This function is only used to record the person using the application, the time, and from what machine. It does not prompt the user for an electronic signature approval. It is only a tracking device and cannot be used with the Real Time Notification or Pre-populate Approver functions. |
Configuring electronic signatures for batch applications is the same as configuring them for interactive applications. However, before you configure an electronic signature for a batch application, you should consider how the batch application is launched. Batch applications can be launched by users from JD Edwards EnterpriseOne menus, or they can be automatically launched by event rules attached to a button in an interactive application. If an OK, Save, or Delete button is configured for an electronic signature approval and that same button contains an event rule that launches a batch application, the system will not launch the batch application until a signature approval is entered for the interactive application. In this case, the system generates a signature record for the transaction on the interactive application, but not the batch application. If a business process requires a signature record each time a batch application is run, then you must create an electronic signature configuration specifically for the batch application.
Consider these different scenarios when configuring electronic signatures for batch applications that are launched by event rules attached to an OK, Save, or Delete button:
If the button and batch application are configured for different signatures, then the system will prompt for two separate signature approvals.
The system records two signature records, one for the interactive application and one for the batch application.
If the button and batch application are configured for the same signature, then the system prompts for a signature for the interactive application and then automatically uses that signature for the signature approval of the batch application. In this case, the system still records two signature records, one for the interactive application and one for the batch application.
If the button is not configured for an electronic signature but the batch application is, then the system only prompts for an electronic signature for the batch application. The system creates only one electronic signature record.
JD Edwards EnterpriseOne enables you to configure the following types of power forms and subforms for electronic signatures:
Power browse forms
Power edit forms
Reusable browse subforms
Reusable edit subforms
Note:
For auditing, there is no special configuration for power forms and subforms because auditing is configured at the table level. A column that is configured for auditing will trigger an audit regardless of the type of form it resides in.You must have a thorough understanding of how power forms and subforms operate before you configure them for electronic signatures. Power forms can contain multiple subforms, embedded or reusable. An OK, Delete, or Save button on a power form can programmatically invoke a Delete or Save button on a subform, and vice versa. You can configure the system to require an electronic signature on a power form, a reusable subform, or both.
You cannot explicitly configure an embedded subform for an electronic signature. Embedded subforms take on the electronic signature configuration of their hosting power form. Therefore, the embedded subform's signature configuration is considered implicit. If a user clicks the Save button on an embedded subform within a power form that has been configured for an electronic signature, the system will prompt for an electronic signature.
When you search on power forms and subforms to configure for electronic signatures, JD Edwards EnterpriseOne only displays power forms and reusable subforms, not embedded subforms.
You can explicitly configure reusable subforms for electronic signatures. A reusable subform configured for an electronic signature acts independently of its hosting power form's configuration. You can configure the reusable subform to prompt for an electronic signature without configuring the power form.
When a reusable subform is not configured for an electronic signature and its hosting power form is, the reusable subform is considered to have an implicit configuration. In this case, the reusable subform operates in the same manner as an embedded subform.
In addition, you can explicitly turn off, or exclude, electronic signatures on a reusable subform. In this case, if a user clicks the Save button on the reusable subform, the system does not prompt for an electronic signature, even if the power form was configured for an electronic signature. For example, you may have a business process that requires you to configure a power form for an electronic signature. However, the power form contains a reusable subform that does not require an electronic signature. In this case, you would explicitly configure the reusable subform to exclude the electronic signature. As a result, when a user clicks the Save button on the reusable subform, the system will not prompt for an electronic signature for the subform.
Note:
You cannot configure electronic signatures at the application level if the application contains a reusable subform.The following table describes the different ways that you can configure power forms and subforms for electronic signatures:
Note:
The scenarios use the OK and Save buttons as examples, but you can also apply these configurations to the Delete button.| Configuration | Result |
|---|---|
| On a power form, the OK button is configured for an electronic signature.
None of the subforms within the power form are configured for electronic signatures. The electronic signature configuration for these subforms is considered implicit. |
Scenario 1:
When a user makes changes on the power form and clicks the OK button, the system prompts for an electronic signature. Scenario 2: When a user makes changes on a subform (embedded or reusable) and clicks the Save button, the system prompts for an electronic signature for the subform. Scenario 3: If the Pass Through Signature option was enabled on the power form during the electronic signature configuration, the system does not prompt for an electronic signature. Instead, it automatically records the user's information in a signature record. Note: The Pass Through Signature option can be used in any of the scenarios described in this table. |
| On a reusable subform, the Save button is explicitly configured for an electronic signature.
The power form is not configured for an electronic signature. |
When a user makes changes on the subform and clicks the Save button, the system prompts the user for an electronic signature. |
| On the power form, the OK button is configured for an electronic signature.
On a reusable subform, the electronic signature on the Save button is explicitly turned off. |
When a user makes changes on the reusable subform and clicks the Save button, the system determines that the electronic signature is explicitly turned off and does not prompt for an electronic signature. |
| On a power form, the OK button is configured for an electronic signature.
On a reusable subform, the electronic signature is explicitly turned off. Note: In this scenario, the OK button on the power form has been programmed to invoke the Save button on the subform. |
When a user makes changes on both the reusable subform and power form and clicks the OK button on the power form:
|
| On a power form, the OK button is configured for an electronic signature.
On a reusable subform, the SAVE button is explicitly configured for a different electronic signature. Note: In this scenario, the OK button on the power form has been programmed to invoke the Save button on the subform. |
When a user makes changes on both the reusable subform and power form and clicks the OK button on the power form:
|
| On a power form, the OK button is configured for an electronic signature.
The reusable subform is explicitly configured to use the same signature as the power form. Note: In this scenario, the OK button on the power form has been programmed to invoke the Save button on the subform. |
When a user makes changes on both the reusable subform and power form and clicks the OK button on the power form:
|
| On a power form, the OK button is configured for an electronic signature.
On a reusable subform, the electronic signature is explicitly turned off. Note: In this scenario, the OK button on the power form has been programmed to invoke the Save button on the subform. |
When a user makes changes on both the reusable subform and power form and clicks the OK button on the power form:
|
| On a power form, the OK button is not configured for an electronic signature.
The power form contains two reusable subforms that are explicitly configured for electronic signatures. The OK button on the power form has been programmed to invoke the Save button on both subforms. |
When a user makes changes on the power form and reusable subforms and clicks the OK button on the power form:
Note: The system does not prompt for an electronic signature on the power form. |
| The electronic signature is configured at the application level.
Note: If the application contains reusable subforms, you cannot set up electronic signatures at the application level. |
When a user makes changes in any of the forms in the application and clicks OK or Save, the system prompts for an electronic signature. |
The system adds a GUID to audit and signature records. You can use the GUID to track the audit and signature records that are associated with the same action. For example, when a user modifies a field configured to trigger an audit and then clicks the OK button configured for a signature approval, the system creates audit and signature records. The system attaches the same GUID to each of these records. You can use this GUID when reviewing and creating reports of audit and signature records that are associated to a particular action.
A GUID can be created in different ways. The following tables shows how a GUID is created in the various database programs:
For Oracle:
| Action | GUID | CFRMKEY | CFRPID | CFRUSER |
|---|---|---|---|---|
| Interactive OW Application | GUID passed from JDB | mkey from JDB | pid from JDB | user from JDB |
| Interoperability Applications | "OW without GUID" | hostname | program name | login_userID |
| Direct Table Operations | "Third Party" | hostname | program name | login_userID |
For IBM DB2 for LUW (Linux, UNIX, Windows):
| Action | GUID | CFRMKEY | CFRPID | CFRUSER |
|---|---|---|---|---|
| Interactive OW Application | GUID passed from JDB | mkey from JDB | pid from JDB | user from JDB |
| Interoperability Applications | "OW without GUID" | "OWNOGUID" | "OWNOGUID" | $USER |
| Direct Table Operations | "Third Party" | "3RDPARTY" | "3RDPARTY" | $USER |
For DB2 for IBM i:
| Action | GUID | CFRMKEY | CFRPID | CFRUSER |
|---|---|---|---|---|
| Interactive OW Application | GUID passed from JDB | mkey from JDB | pid from JDB | user from JDB |
| Interoperability Applications | "OW without GUID" | "OWNOGUID" | "OWNOGUID" | "OWNOGUID" |
| Direct Table Operations | "Third Party" | "3RDPARTY" | "3RDPARTY" | "3RDPARTY" |
For SQL Server:
| Action | GUID | CFRMKEY | CFRPID | CFRUSER |
|---|---|---|---|---|
| Interactive OW application | GUID passed from JDB | mkey from JDB | pid from JDB | user from JDB |
| Interoperability applications | "OW without GUID" | host_name() | "OWNOGUID" | user_name() |
| Direct Table Operations | "Third Party" | host_name() | "3RDPARTY" | user_name() |
This section provides an overview of the auditing and electronic signature configuration for a pathcode and discusses how to:
Set up an audit only configuration for a pathcode.
Set up an audit and electronic signature configuration for a pathcode.
Modify an existing configuration.
Review configuration changes.
Before you configure auditing and electronic signatures for interactive or batch applications, you must set up an auditing and electronic signature configuration for a pathcode. You can set up an audit-only configuration or a configuration for both auditing and electronic signatures.
When you use the Configuration Application (P9500001) to set up a pathcode for auditing and electronic signatures, you must make sure that you are signed into JD Edwards EnterpriseOne using the pathcode for which you want to enable auditing and electronic signatures. The auditing and electronic signature configuration is recorded in the F9500001 table in the database. A history of all changes to the configuration is recorded in the Security History table (F9312).
Note:
Configuring auditing and electronic signatures for more than one pathcode is not supported.An Audit Only configuration is used to record only tables with changes, not electronic signatures.
Enter P9500001 in the Fast Path.
Note:
P9500001 is available on the Microsoft Windows client and the web client.On the Work with Configuration Settings form, click Add.
On the Configuration Setting Revisions form, select the Auditing check box.
The Pathcode field contains the pathcode to which the settings are applied, which is also the pathcode that you are signed in to. This field cannot be modified.
Make sure that the Signature check box is not selected, and then click OK.
On the Enable/Disable Auditing form, in the Password field, enter a password for enabling or disabling auditing.
The password that you enter here is the password that you must enter if you enable or disable auditing for a particular table.
Click OK.
Enter P9500001 in the Fast Path.
Note:
P9500001 is available on the Microsoft Windows client and the web client.On the Work with Configuration Settings form, click Add.
On the Configuration Setting Revisions form, select the Signatures check box.
The Pathcode field displays the pathcode where the settings are applied. This defaults to the pathcode that you are signed in to and cannot be modified.
The Auditing check box is automatically checked if Signatures is selected. You cannot clear this check box.
Select any of the following options, as appropriate:
Pass Through User
Records the user ID of the person using the application, the time of the electronic signature approval, and the machine name.
Pre-populate Approver
Automatically uses the user's JD Edwards EnterpriseOne sign-in information for the first and second approval, depending on the configuration for the number of approvers.
Real Time Notification
Sends a notification to a specified user if a signature fails.
Note:
You can only use these options if they were enabled at the pathcode level.See Enabling Auditing and Electronic Signatures for a Pathcode.
In the Default Signature Context field, enter the signature context for the pathcode, and then click OK.
This text appears on the Signature Capture form unless a specific signature context has been defined at the application level.
On the Enable/Disable Auditing form, in the Password field, enter a password for enabling or disabling auditing, and then click OK.
The password that you enter here is the password that you must enter if you enable or disable auditing for a particular table.
Enter P9500001 in the Fast Path.
Note:
You can only change a configuration for the pathcode that you are signed into. However, all pathcode configurations may be viewed through this application. You can turn on or turn off the auditing or signature configuration, as well as change the Pass Through User, Real Time Notification, and Pre-populate Approver features for electronic signatures.On the Work With Configuration Settings form, select the current pathcode and then click Select.
On the Configuration Setting Revisions form, edit the desired parameters noting that:
Auditing must be disabled for all tables before disabling auditing at the pathcode level.
Disabling electronic signatures does not turn off the auditing function. After disabling signatures, you can then clear the Auditing check box if you want to turn off auditing for the pathcode.
Click OK.
On the Enable/Disable Auditing form, if you disabled or enabled auditing, complete the Password field and then click OK.
Changes made to the configuration can be viewed by using the User Security application (P98OWSEC). This application displays any changes made to the configuration.
This section provides an overview of auditing restrictions and discusses how to:
Configure a table for auditing.
Check in an audit table.
Modify an existing audit table.
Verify and reset audit tables.
Copy an audit table configuration.
Audit columns within audited tables are set to a protected status by TDA to prevent columns from being modified or deleted after the table is enabled for auditing. Therefore, the following restrictions apply:
You cannot remove columns once auditing is enabled for a table.
You cannot change the order of the columns once auditing is enabled for a table.
Enter P9500003 in the Fast Path, or enter GH9091 and then select the Audit Table Configuration menu.
On the Work with Audit Table Configuration form, click Add.
On the Audit Table Setup Director, click Next.
On the JD Edwards EnterpriseOne Table Selection form, in the Table Name field, enter the name of the table that you want to audit, and then click Next.
Alternatively, you can click the Find button and select a table from the list.
Note:
If a table was previously configured for audit, it cannot be selected.On the Audit Table Information form, if necessary, make changes to the default values, and then click Next.
This action launches TDA in audit mode, which creates audit table specifications locally and adds the audit table to your default project in OMW.
By default, the Primary Key columns from the original table are populated along with eight more columns, which are mandatory for the audit table.
In the Auditable Columns area, select the columns that you want to trigger an audit and move them to the Columns area. You can append new columns to the end of the audit table, but they cannot be inserted between existing columns or reordered.
In the Auditable Columns area, select any additional columns that you want recorded in the audit table and move them to the Columns area. Right-click the column and then select Audit Trigger Column.
This action removes the check mark from this option so that the column will not trigger an audit. Instead, this column will be recorded along with the other columns in the audit table when an audit is triggered.
Click Save and then close TDA after all columns have been selected for auditing.
On the Work with Audit Table Configurations form, click End.
Restart all servers and clients.
Note:
After you complete the configuration, you must enable the table for auditing in JD Edwards EnterpriseOne.Checking in an audit table moves the audit table from the local specifications to the check in location specified in the OMW transfer activity rule.
Enter P9500003 in the Fast Path, or enter GH9091 and then select the Audit Table Configuration menu.
On the Work with Audit Table Configurations form, select the table to check in.
From the Row menu, select Check In Table.
When you modify an existing audit table, the system checks out the object to your default project in OMW and enables you to append columns to the audit table using TDA.
Enter P9500003 in the Fast Path or enter GH9091 and then select the Audit Table Configuration menu.
On the Work with Audit Table Configurations form, select the table that you want to modify.
From the Row menu, select Set Up Revisions.
On the Audit Table Configuration form, click OK.
The system launches TDA.
In TDA, you can move columns from the Auditable Columns area to the Columns area to append columns to the existing audit table.
In the Auditable Columns area, select any additional columns that you want recorded in the audit table, and move them to the Columns area. Right-click the column and then select Audit Trigger Column to clear the check mark from this option.
This action ensures that the column is recorded along with the other columns in the audit table when an audit is triggered. However, this column will not trigger an audit.
Click Save, then exit TDA after all columns have been appended for auditing.
On the Work with Audit Table Configurations form, from the Row menu, select Check In Table.
This section explains how to check the configuration for a given table across all environments and databases within the pathcode and explains how to reset the auditing state for the selected audit table if a conflict is detected. Perform this task when the JDE.log or JAS.log file indicates conflicts with audited tables between environments.
Enter P9500003 in the Fast Path, or enter GH9091 and then select the Audit Table Configuration menu.
On the Work with Audit Table Configurations form, select the audit table that you want to verify.
From the Row menu, select Verify.
On the Validate and Reset Database Audit Components form, enter a database password in the Password field, and then click OK.
If the audit configuration is valid, the system displays the Work with Audit Table Configurations with an informational message, "Database Audit Components valid."
If the audit configuration is not valid, the following error is returned on the Validate and Reset Database Audit Components form: Error: Database Audit Component States Differ. From the Form menu, select Reset Audit Flag to reset database audit components.
Click OK on the message box reminding you to bounce servers and clients.
Click Find to refresh the Work with Audit Table Configurations form. Verify that the Audit table shows the correct state: Enabled or Disabled.
If the audited tables reside in a data source shared between environments within the same pathcode, use the copy table function to add the audit table configuration to each environment.
JD Edwards EnterpriseOne requires that you copy the audited table configuration to the other environments prior to enabling auditing. Auditing the table only in one environment causes the other environments to fail in the application that uses that particular table, rolling back the transaction. The JDE.log and JAS.log files indicate conflicts with audited tables between environments.
Sign in to the environment where the audit configuration needs to be set up, and then access the Work with Audit Table Configurations form.
On the Work with Audit Table Configurations form, from the Form menu, select Copy Audit Table.
On the Copy Audit Table Information form, find and select the table to be copied.
Verify that the selected audit table is in the configuration tree.
Note:
JD Edwards EnterpriseOne displays only the tables that have been set up for a different environment, checked in to the shared data source, and are missing from the audit configuration for the signed-in environment.This section discusses how to:
Enable auditing for a table.
Disable table auditing for an Oracle, SQL Server, or DB2 for IBM i database.
Disable table auditing for a IBM DB2 for LUW (Linux, UNIX, Windows) database.
This section describes how to enable auditing for the desired table after auditing has been enabled for the pathcode.
Note:
Make sure that all users are signed off the system and no batch jobs are running on the server.Enter P9500003 in the Fast Path, or enter GH9091 and then select the Audit Table Configuration menu.
On the Work with Audit Table Configurations form, select the audit table.
From the Row menu, select Enable DB Auditing.
On the Enable/Disable Database Auditing Components form, enter the database password in the Password field.
Click OK to enable auditing for the table.
The application reminds you that all users must be signed out of JD Edwards EnterpriseOne and all enterprise and HTML servers must be restarted.
Note:
You only need to restart all servers and clients once, after the configuration for all tables and objects are complete.Click OK.
The audit table record in the Work with Audit Table Configurations tree indicates that auditing is enabled for the table.
Before performing this task, make sure that all users are logged off the system and that no batch jobs are running on the server.
Note:
Disabling auditing for a table does not remove the table from the audit list.On the Work with Audit Table Configurations form, select the audit table.
From the Row menu, select Disable DB Auditing.
On the Enable/Disable Database Auditing Components form, enter the database password in the Password field.
Click OK to disable auditing for the table.
The system displays a message recommending that you bounce all servers and clients.
Note:
You have to bounce all servers and clients only once, after the configuration of all tables and objects is complete.Click OK.
The Work with Audit Table Configurations form displays the Audit table record in the tree control and indicates that auditing is disabled.
Before performing this task, make sure that all users are logged off the system and that no batch jobs are running on the server.
Note:
Disabling auditing for a table does not remove the table from the audit list.From the Start menu, select IBM DB2, Command Window to start a DB2 Command Window.
Sign in to the database with a user who has a DBADM privilege.
Collect Table Space information for the Specified table with this SQL Command:
SELECT TBSPACE, INDEX_TBSPACE, LONG_TBSPACE FROM
SYSCAT.TABLES where TABNAME = ERPTable (with '') and
TABSCHEMA=schema (with'')
Write down the table space names for table, index, and long data, respectively.
Create the temporary table with this SQL command:
CREATE TABLE schema.ERPTable_temp LIKE schema.ERPTable (VIEW) IN tbspace INDEX IN⇒ index_tbspace LONG IN long_tbspace NOT LOGGED INITIALLY
Note:
The table space names were collected from step 4: tbspace for table, index_tbspace for index, and long_tbspace for long data.Run the SQL command in step 3 against the new temporary table to ensure that it has been created in correct table spaces.
Copy data from the view to the temporary table with this SQL command:
INSERT INTO schema.ERPTable_temp SELECT * FROM schema.ERPTable (VIEW)
Note:
This process may take a few minutes to complete depending on the size of the table.To ensure that all data was copied, run the following SQL commands against the view and the temporary table:
SELECT COUNT(*) FROM schema.ERPTable_temp
SELECT COUNT(*) FROM schema.ERPTable
The results of running both commands should be same.
Use this SQL command to drop the view:
DROP VIEW schema.ERPTable
Use this SQL command to drop the ADT table:
DROP TABLE schema.ERPTable_ADT
Rename temporary table with the original JD Edwards EnterpriseOne table name:
RENAME schema.ERPTable_temp TO ERPTable
Use this SQL command to grant privileges to PUBLIC for the new table:
GRANT SELECT, INSERT, UPDATE, DELETE, ALTER, INDEX, REFERENCES ON TABLE⇒ schema.ERPTable TO PUBLIC
Sign in to JD Edwards EnterpriseOne client and then enter OMW in the Fast Path to access OMW.
Use Table Design Toolset to generate indices for this table.
Run "Verify and Reset" using the Work With Audit Table Configuration form.
You must set up reason codes before you configure electronic signatures. This section discusses how to:
Add a reason code.
Change the status of a reason code.
Copy a reason code.
Enter P9500002 in the Fast Path.
On the Work with Reason Codes form, click Add.
On Reason Code Revisions, in the Reason Code field, enter a number for the reason code.
In the Language field, enter the language code for the reason code.
In the Reason Code Description field, enter a description for the reason code.
Select the Active or Inactive option, as appropriate, and then click OK.
Note:
A warning message appears to verify that the spelling of the reason code description is correct. Reason codes cannot be deleted.Changing the status of a reason code changes it from active to inactive or vice versa.
On the Work with Reason Code form, select the desired reason code.
Under the Row menu, select Change Status.
Note:
You cannot change the status of a reason code if it is the default reason code in an electronic signature configuration.Copying a reason code copies all fields except the reason code number.
Select the desired reason code to copy and then click Copy.
Change the desired field and provide a new reason code number.
Click OK.
Use the Object and Table Configuration (P9500003) application to set up interactive or batch application to require electronic signatures. This section lists a prerequisite and discusses how to:
Set up an electronic signature configuration for an interactive application.
Set up an electronic signature configuration for a batch application.
Modify an electronic signature configuration.
Delete an electronic signature configuration.
You must define reason codes before you set up electronic signatures.
Enter GH9091 in the Fast Path, and then select Interactive and Batch Signature Configuration.
On the Work with Object Signature Configurations form, click Add.
On the Interactive and Batch Applications Signature Setup Director, select the Interactive Application/Signature Setup option, and then click Next.
On the Interactive Application Selection form, select the desired application, and then click Next.
Note:
Objects with a check mark next to them have already been configured.On the Interactive Forms Search and Select form, select a form. If all forms for an application are desired, select the Application Level check box.
Note:
Applications with reusable subforms cannot be configured at the application level.Click Next.
Note:
If there is a padlock button to the left of the Form Name, this form already has the OK and Delete events set up and cannot be selected. Instead, this form must be selected from the Work with Signature Object Configurations form. Select Setup Revisions from the Row menu to revise an existing configuration.A plus sign (+) indicates that an OK event has already been set up for this form.
A minus sign (−) indicates that a Delete event has already been set up for this form.
On the Interactive Application Signature Information form, in the Events area, select OK, Delete, or both to indicate the function that requires a signature.
For a reusable subform, you can select the "Exclude Subform from Signature Configuration" option.
This option is available only for reusable subforms. If the hosting power form is configured for an electronic signature, you can select this option if you do not want the system to prompt for a second electronic signature on the reusable subform.
Select one of these options:
Pre-populate Approver
Select this option if you want the authorization fields to automatically use the session's user information.
Pass Through User
Select this option if no signature prompting is necessary when the application is run. The signature table is updated with the signed on user's information.
Note:
You can select either the Pre-populate Approver or Pass Through User option. They cannot be selected together.If the Pass Through User is on, the number of signatures is forced to one and the role is disabled.
Enter the number of signatures required to approve the transaction: 1 or 2.
In the Default Reason Code field, enter the default reason code for the signature approval.
In the Role field, enter the role of the approver.
In the Real Time Notification field, enter the user ID or email address of the user to be notified if the electronic signature fails.
The user is notified after four failed attempts.
In the Signature Context field, enter a text message that you want to display on the Signature Approval form, and then click Next.
On the Work with Object Signature Configurations form, click End.
Enter GH9091 in the Fast Path, and then select Interactive and Batch Signature Configuration.
On the Work with Configurations form, select Object Setup from the Form menu.
On the Work with Object Signature Configurations form, click Add.
On the Interactive and Batch Applications Signature Setup Director, select the Batch Application / Signature Setup option, and then click Next.
On the Batch Application Selection form, select the desired batch application, and then click Next.
Note:
Objects with a check mark next to them have already been configured.On the Batch Application Signature Information form, select one of these options:
Pre-populate Approver.
Select this option if you want the authorization fields to automatically use the session's user information.
Pass Through User.
Select this option if no signature prompting is necessary when the application is run. The signature table is updated with the signed on user's information.
Note:
Pre-populate Approver and Pass Through User cannot be selected at the same time.If the Pass Through User is on, the number of signatures is forced to one and the role is disabled.
Enter the number of signatures required to approve the transaction: 1 or 2.
In the Default Reason Code field, enter the default reason code for the signature approval.
If a role is required, enter the role of the approver in the Role field.
In the Real Time Notification field, enter the user ID or email address of the user to be notified after four failed signature attempts.
In the Signature Context field, enter a text message that you want to display on the Signature Approval form, and then click Next.
On the Work with Object Signature Configurations form, click End.
Enter GH9091 in the Fast Path, and then select Interactive and Batch Signature Configuration.
On the Work with Object Signature Configurations form, select the interactive application, event, or batch application to modify.
Select Setup Revisions from the Row menu.
Depending on the type of application that you are modifying, the system displays either the Interactive Application Signature Information form or Batch Application Information form
Make changes and then click OK.
Verify that the properties have changed for the interactive application, event, or batch application.
Note:
All servers and clients need to be restarted once after the auditing and electronic signature configuration of tables and applications (interactive or batch) is complete. Any changes that you make to the auditing or electronic signature configuration will require services to be restarted on all servers and clients.Enter GH9091 in the Fast Path, and then select Interactive and Batch Signature Configuration.
On the Work with Object Signature Configurations form, click Find and then select the interactive application event or batch application to delete.
Click Delete.
Verify that the interactive application, event, or batch application has been removed from the tree on the Work with Object Signature Configuration form.