Introduction to auditing FSCs

Teamcenter provides flexible and detailed auditing of FSC access and operations. The primary purpose of this auditing functionality is to track system access for security purposes. It also allows monitoring of the servers for operational purposes and can be used to debug or verify complex FMS system interactions. After FSC audit logging is configured, the audit logs are written to %USERPROFILE%\Siemens\logs\FSC\process\fscid_audit.log files. As server requests are processed, each request is identified by a transaction ID. The audit log output is generated as the requests are processed by the server. A single request/transaction can propagate across various FSC servers. However, they are easily identified and correlated in all of the participating FSC audit log files. You can import the audit log information into standard text or word processors for correlation and examination. Teamcenter provides configurable audit points for different types of processing: Request Identified by request in the audit log. It is at the top of the request processing chain before any routing within the server. It can render HTTP request information, the transaction ID, and ticket information if it is provided with the request. Request information can include HTTP request headers, remote address, and so forth. Primary operation start Identified by priopstart text in the audit log. This is the primary operation starting audit point. It signals a ticketed operation start event. It can render the same information as the request audit point. It includes a short description of the operation indicating how the request is being processed. Primary operation stop Identified by priopstop text in the audit log. This is encountered once a primary request is finished processing. All request and operation start renderers are available as well as operation stop and response renderers. Subordinate operation start Identified by subopstart text in the audit log. This is a subordinate operation starting audit point. It can render the same information as the request audit point. It includes a short description of the operation indicating how the request is being processed. Tickets in subordinate operations may differ from the tickets used in primary operation tickets. Subordinate operation stop Identified by subopstop in the audit log. This is processed once a subordinate operation is finished processing. All request and operation start renderers are available as well as operation stop and response renderers. Web operation start Identified by webopstart text in the audit log. This is a simple web server-like operation start audit point, such as a configuration download, favicon request, or other non-ticketed requests. It can render request information, such as a header, remote address, and the transaction ID. The operation indicates how the request is processed. Web operation stop Identified by webopstop text in the audit log. This is processed after a simple web server-like operation has finished processing. All operation start renderers are available as well as operation stop and response renderers. If all audit points are enabled, the simplest request generates at least three audit log outputs. Ticketed requests include request, priopstart, and priopstop audit points. Non-ticketed requests include request, webopstart, and webopstop audit points. You can configure only the audit points desired. You can also configure only the information of interest for output. For example, for minimal output, all audit points can be disabled except for priopstop and webopstop. This provides information on each request without generating multiple output lines for each request. This does not show subordinate operations because they are not a concern.