Auditing
Sign In
The Oracle Fusion Cloud Transportation Management and Global Trade Management service have the user sign in auditing functionality enabled by default. This means that every interactive user sign in will have a record of the sign in. A sign in history record is created and if the user was successfully authenticated, the Last Login Date on the User record will be updated as well.
When you configure a custom account policy for individual users you can also specify to Keep Login history. When this option is enabled, it will also create a sign in history record and will update the Last Login Date of the user.
The Login History user interface can be used to audit user sign in attempts. This user interface shows an administrator a user’s sign in attempt, sign in status, and sign in time.
- Configuration and Administration > User Management > Login History
Data Auditing
The Oracle Fusion Cloud Transportation Management and Global Trade Management service have a data auditing capability. Many of the service functions can be audited. Ultimately, all business functions act upon business objects that store data in a database table. Within the service you can audit user interface business actions, agent actions, events related to data change, and get actual data change information. The data change information is available for all database columns within the tables that make up a business object. The business object is referred to as a data query type. All the major entities are data query types. You can configure by a domain or globally what data query types need to have the audit trail capability. You can also enforce their users to provide event reasons for running particular user interface actions, which would give the audit information context as to why to the data needed to be changed. There's also the capability to capture the pre-changed and post-change data information.
There's a lot of information that's recorded in an audit record. This information includes the user interface action or agent action, the event reason and associated comments, the time the data modification took place, the business object ID, the table name, the database action taken, and the pre and post data changes. There's minimal service performance overhead associated with using the data auditing capabilities.
You can also control what users have access to audit log data. Typically a service Administrator or domain level Administrator should be responsible for reviewing and/or purging the audit logs. Some audit data is available with just the DEFAULT user role and Audit ACL, but to see all audit details, a user would need to also have the Administration ACL. You can review the audit trail records by using the Audit Trail Management user interfaces. These include the Audit Trail Manager, the Audit Trail By User, Audit Trail By Event, and the Audit Trail By Notification managers. There are also application SmartLink user interfaces available on the business entities managers for the Data Query Types that support the audit capability. These SmartLinks are links to the Audit Trail Data just for that particular business object.
The service provides a capability for purging audit trail records. The purging can be done by the data query type or business object. The purging of the audit trail records isn't tied to the actual business object’s purge. This means that when there's a purge of the business objects, it will not automatically purge the audit trail records. To purge the audit trail records an extra purge will need to be scheduled to clean up these related records.
The following property enables extra behavior to compare the before and after values.
glog.audit.beforeafter=[on|off]
Configuration Change Auditing
See the Audit Events help topic for details on viewing historical changes made to configuration and access. Access to Property Servlets, Property Set, Optional Feature, and Logic Configuration User Interfaces should be restricted by user role and access control list assignments. Use the Audit Events functionality to supplement your formal change control process so that you know when and why something was changed.