Review the Log Files for the Details

After setting the logging and restart the AI service and Server component, log into the Siebel Client UI or send an inbound request to the EAI OM component.

Then, check for these files in AI log directory after using the above logging setting:

  1. <AI>\applicationcontainer_external\logs\CommonLogger.log: This file shows the gateway returning the ConnectString to the server/OM component that the request will be sent to.

  2. <AI>\applicationcontainer_external\logs\localhost_access_log.<DATE>.txt: This localhost_access_log.<DATE>.txt shows the request that came through the AI instance.

    The first field shows the IP Address of where the request came from (%h - Remote hostname (or IP address if the resolveHosts attribute is set to false; by default the value is false)).

    Note: Recall the server.xml file AccessLogValve section was modified to include additional text so it now shows more description for the time and http status code with the following:
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
    prefix="localhost_access_log" suffix=".txt"
    pattern="%h %l %u Begin Time: %{begin:yyyy-MM-dd HH:mm:ss.SSS}t, End Time: %{end:yyyy-MM-dd HH:mm:ss.SSS}t &quot;%r&quot; Response Commit Time %F ms, Request Processing Time %D ms,
    http %s, IContentLength %{Content-Length}i bytes, OContentLength %b bytes, %{SOAPACTION}i" />
    
    Note: Recall the server.xml file AccessLogValve section was modified to include additional text so it now shows more description for the time, http status code, request begin and end times, etc.
  3. <AI>\applicationcontainer_external\logs\siebel_1.log:

    The siebel_1.log shows which Siebel server Host machine name, Component OM PID Value and TaskId the request is routed to.
    Note: This [HOST/PID/TaskId] information in the siebel_1.log file is only seen for Inbound Web Services using Session Management and for Inbound REST Connections.
    Note: The [HOST/PID/TaskId] does not show up in the siebel_1.log file for Inbound Web Service Anonymous Pool connections, for more information see, [Inbound Web Service Anonymous Pool] .
  4. For EAI OM or any Siebel OM component:

    Check the Siebel server siebsrvr\log directory on the server HOSTNAME shown from the above siebel_1.log file:

    1. Check for the Object Manager log for the component. Example EAIObjMgr_enu_*.log for EAI OM component, or SCCObjMgr_enu_*.log for Call Center ENU

      In particular, locate the OM log file with the ending TaskId which matches what is shown in the above siebel_1.log file.

      Open the OM log file to inspect the first line to confirm it matches the ProcessId and TaskId value from the siebel_1.log file.

    2. If the calls are for Inbound Web Services, check for Inbound_*.dmp file on the same Siebel server host machine where the EAI OM task log files are found.

      These Inbound_*.dmp files come in pairs:

      • InboundDispatcher_input_args_<TaskId>.dmp - This contains the inbound SOAP request received by Siebel.

      • InboundDispatcher_output_args_<TaskId>.dmp- This contains the SOAP response sent out from Siebel. The SOAP response may be a SOAP fault message if your inbound request was not valid.

      The ending TaskId value of these Inbound_*.dmp file should match the ending TaskId of an EAIObjMgr_enu log file as well. This means, that a particular EAIObjMgr_enu task processed that particular inbound message captured in the Inbound_*.dmp file with the same TaskId value.

      If the Web Service uses Session Management and SessionToken, then one would also see these .dmp file followed by numbers such as (1), (2), (3) .... (N) with the same TaskId, which means that the same EAIObjMgr_enu task was opened and remained open to process these requests coming in with SessionToken values. This is one way to determine how many inbound web service requests were processed by a particular EAIObjMgr_enu task.

      Within the Inbound_*.dmp file, there are also actual payload and SessionToken, this will allow an administrator to find out which Siebel server, component, task that the particular request was routed to and handled by.