Purpose: A variety of logs are available to help troubleshoot Order Management System processing:
• CWDirect Log: to review messages generated by the Order Management System application server at startup and during Order Management System processing, such as when the application receives an invalid character in an XML message, or when a submitted job encounters an error.
• Order Management System Application Logs: to review activity such as:
• processing by the Order Management System job scheduler
• email notification processing
• creation, change, or deletion of a record in Order Management System
also, you can use these logs to troubleshoot situations such as:
• occasions when a stored value card or authorization job requires user intervention in order to proceed due to error or communication failure
• communication problems between Order Management System and the PC manifest station
• communication problems between Order Management System and PayPal when using the PayPal Direct Connection Integration
Information related to application logs:
• Location of Order Management System Application Logs
• Sensitive Data in Application Logs
• MQ Log
• IntegrationOrder (ChannelAdvisor) Log
• OCDS (Omnichannel Cloud Data Service) Log
• ORCE (Oracle Retail Customer Engagement) Log
• OROB (Oracle Retail Order Broker) Log
• RICS Log
Use this log to review messages generated during processing of the Order Management System application.
Location of file: This file is normally saved on the application server at /domain/log/CWDirect.log, where domain is the WebLogic domain directory for Order Management System.
To review the file: You can review the contents of this file using a text editor.
Special characters in the CWOrderIn message: If you pass a special character that is not properly encoded in the Header element of the Inbound Order XML message (CWOrderIn), the system does not process the message and logs the error in the CWDirect log.
Example:
If you pass Mary&Joe in the sold_to_fname tag, an error message similar to the following is in the CWDirect log:
2008-06-18 11:25:59,934 99184497 ERROR [STDERR] (43049:) (LoggerStream.java:152) [Fatal Error] :1:214: The reference to entity "Joe" must end with the ';' delimiter.
If you pass Mary& in the sold_to_fname tag, an error message similar to the following is in the CWDirect log:
2008-06-18 11:10:29,315 98253878 ERROR [STDERR] (43049:) (LoggerStream.java:152) [Fatal Error] :1:110: The entity name must immediately follow the '&' in the entity reference.
Email errors: If the mail.debug setting in Working with Admin Properties (CPRP) is true, the system includes error messages about email generation in the CWDirect log. For example, if a program defined for a periodic process is not a valid program, an error message similar to the following is in the log:
2008-06-20 16:08:44,868 169401020 ERROR [JENASYS] (43298:) (JenasysJob.java:307) execute(): com.mincron.framework.BusinessLogicException: Program name=[Xx123456] not found.
2008-06-20 16:08:44,868 169401020 ERROR [JENASYS] (43298:) (JenasysJob.java:699) run(): Job status change to [MSG]. execute(): com.mincron.framework.BusinessLogicException: Program name=[Xx123456] not found.
In addition, the system generates a Order Management System Support Notification indicating the job has been placed in MSG status due to an error during processing; see Order Management System Support Notifications for more information.
Errors for submitted jobs: To see if the system has written a log message for an error that occurred during a submitted job, search for the Job number displayed at the Job Management screen. For example, the following message indicates a problem with submitted job 3133:
2014-11-20 14:14:12,852 ERROR [JENASYS] (197213%Thu Nov 20 14:14:11 EST 2014) -MonitorOutputQueues- processServiceRequest: could find/load properties filr for the queue = [QPRINT]
Changes to queues for jobs: When a user has moved a job to a different queue at the Job Management (My Jobs) screen, the system writes a message such as the following:
Queue Change: User USERNAME has moved job number 123456 / name IJCTSTART from queue QBATCH to queue QSYSNOMAX
Order Management System Application Logs
Purpose: Use the following logs to review the processing that occurred on the Order Management System application server.
• MQ Log
• IntegrationOrder (ChannelAdvisor) Log
• OCDS (Omnichannel Cloud Data Service) Log
• ORCE (Oracle Retail Customer Engagement) Log
• OROB (Oracle Retail Order Broker) Log
• RICS Log
Location of Order Management System Application Logs
The CW_LOG_DIR setting in Working with Admin Properties (CPRP) defines the directory path on the application server where the logs are located.
An example directory is /domain/conf/OMSFiles/Logs/, where domain is the WebLogic domain directory for Order Management System.
The LOG_LEVEL in Working with Admin Properties (CPRP) defines the level of detail to include in the log.
• ALL = Include all levels of information in the log, including debug statements, informational statements, warnings, errors, and fatal statements. This is the most detailed level of logging.
• DEBUG = Include debug, or detailed informational event statements in the log, as well as informational, warning, error, and fatal statements.
• INFO = Include informational statements in the log, as well as warning, error, and fatal statements. Do not include debug statements in the log.
• WARN = Include warning statements in the log, as well as error and fatal statements. Do not include debug or informational statements in the log.
• ERROR = Include error, or serious issue, statements and fatal statements in the log. Do not include debug, informational, or warning statements in the log.
• FATAL = Include fatal statements on actions that cause the application to abort in the log. Do not include debug, informational, warning, or error statements in the log. This is the highest level of logging.
• OFF = Do not create a log.
Logging Level Illustration:
The MAXBACKUP_DAYS setting in Working with Admin Properties (CPRP) defines the number of days the system stores a backup copy of the log before deleting. For example, if the MAXBACKUP_DAYS setting is set to 30d, the system stores a backup copy of the log for 30 days before deleting it.
Note: The entry in this field must include the letter d, as in 30d.
When is a log archived? Each day at midnight, the system archives the current log, adding a zip file extension and date to the log name. For example, if the current date is 02/05/2008, the system archives the APP.log, renaming the file from APP.log to APP.2008-02-05.log.zip.
Note: The system does not create a new log until activity occurs to write to the log. For example, the system does not create a new APP.log until application activity occurs. The LOG_LEVEL determines when the system writes a message to the APP.log.
Sensitive Data in Application Logs
Order Management System masks sensitive data, such as credit card number, CID number, account number, and all personal data (person or company name, mailing address, email address, phone number, and so on) in the application logs. The system uses the XML Removed by Logger table to determine which message tags are masked in the log files. This table lists all message tags that contain sensitive data. If a tag in a message matches a message tag in this table, Order Management System masks the value in the tag; otherwise, the actual value displays.
Note: Masking only applies to message tags, or attributes, in the message. You cannot apply masking to a message element.
Use Working with Admin Properties (CPRP) to define the type of information the system includes in the Order Management System application logs.
Setting |
Description |
|---|---|
The directory path on the Order Management System application server where the logs are located. An example directory is /domain/conf/OMSFiles/Logs/, where domain is the WebLogic domain directory for Order Management System. |
|
CW_LOG_ BACKUP_ PATTERN |
The file extension added to backup copies of the log file. The system creates a backup copy of the log file for each day, using the date format from the CW_LOG_DATE_PATTERN setting and file extension from the CW_LOG_BACKUP_PATTERN setting. For example, for the APP.log file, the system names the backup copy APP.YYYY-DD-MM.log.zip. The delivered setting is .zip. Note: The file extension must be lower case. |
CW_LOG_DATE_PATTERN |
The date format for backup copies of the log file. The system creates a backup copy of the log file for each day, using the date format from the CW_LOG_DATE_PATTERN setting and file extension from the CW_LOG_BACKUP_PATTERN setting. For example, for the APP.log file, the system names the backup copy APP.YYYY-DD-MM.log.zip. The delivered setting is .%d{yyyy-MM-dd}.log. |
CW_LOG_DATAQ |
Defines whether the system includes messages written to data queues in the log. Valid values: true = The system includes messages written to data queues in the log. false = The system does not include messages written to data queues in the log. |
|
Use the MQ.log to track XML and transactional messages generated or received by Order Management System that are not tracked in the Application Log, Manifest Log, Order Log, or Trace Log. You can use this file to confirm that you are receiving or generating messages correctly, to isolate communication problems, or to recover information. |
|
MQ_LOG_LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
MQ_ MAXBACKUP_ DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
|
This log is not currently implemented. |
|
|
Use the APP.log to track the activity performed in the Order Management System application, such as: • the processing that occurs in the Order Management System job scheduler • email notification processing • when a user creates, changes, or deletes a record in Order Management System |
|
APP_LOG_LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
APP_ MAXBACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
|
Use the RESP.log to review when a job required user intervention in order to proceed. A job may require user intervention if: • an error occurs during processing • the job sends transactions to another system, and communication failures occur before the transmission completes The types of job that require user intervention: • stored value card (activation, balance inquiry, or authorization reversal) • authorization (batch only, for all card types) • deposit |
|
RESP_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
RESP_ MAXBACKUP_ DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
|
Use the TRACE.log to review internal messages about Order Management System application processing. Typically, you review this log only if the contents of the Application Log did not help you. |
|
TRACE_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
TRACE_ MAXBACKUP_ DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
|
Use the MANIFST.log to review the messages between Order Management System and the PC manifest station. You can use this log to confirm that communication between Order Management System and the PC manifest station is working correctly, to isolate communication problems, or to recover information. Any errors that occur during processing are also in this log. |
|
MANIFEST_LOG_LEVEL |
Defines the level of detail included in the log. See Logging Level. |
MANIFEST_MAXBACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
|
Use the ORDER.log to review the messages between an external system and Order Management System through the Generic Order Interface (Order API). You can use this log to confirm that communication between the external system and Order Management System is working correctly, to isolate communication problems, or to recover information. |
|
ORDER_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
ORDER_MAX BACKUP_ DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
|
Use the OROB.log to review the messages between Order Management System and Order Broker when you use the Order Broker Integration. You can use this log, in addition to Order Broker’s logs, to review data passed between the two systems. |
|
OROB_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
OROB_MAX BACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
|
Use the PAYPAL.log to review the messages between Order Management System and PayPal when you use the PayPal Direct Connection Integration. You can use this log to confirm that communication between Order Management System and PayPal is working correctly, to isolate communication problems, or to recover information. Any errors that occur during processing are also in this log. |
|
PAYPAL_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
PAYPAL_MAX BACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
|
Use the ALERT.log to review the alerts generated by the Job Monitor Status (WJMO) menu option; see Monitoring Jobs. Note: The system updates this log only if the ALLOW_JOB_ MONITOR and TRACK_ALERTS_IN_LOG settings in the Monitor Properties file are set to Y. These settings should only be set to Y for the application server that allows job scheduling; see How to Schedule a Job. See the Alert Log for more information. |
|
ALERT_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
ALERT_MAX BACKUP_ DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
IntegrationOrder (ChannelAdvisor) Log Use the IntegrationOrder.log to review activity related to integration with ChannelAdvisor. Note: The system updates this log only if the you use the ChannelAdvisor integration. See ChannelAdvisor Integration Overview for background. See the IntegrationOrder (ChannelAdvisor) Log for more information. |
|
INTEGRATION ORDER_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
INTEGRATION ORDER_MAX BACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
OCDS (Omnichannel Cloud Data Service) Log Use the OCDS.log to review activity related to communication with OCDS to import enterprise foundation information, such as merchandise hierarchy, items, prices, and related data. Note: The system updates this log only if the you use the OCDS integration. See Importing Enterprise Foundation Data through Omnichannel Cloud Data Service (OCDS) for background. See the OCDS (Omnichannel Cloud Data Service) Log for more information. |
|
OCDS_LOG_LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
OCDS_MAXBACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
ORCE (Oracle Retail Customer Engagement) Log Use the ORCE.log to review activity related to the loyalty integration with Oracle Retail Customer Engagement. Note: The system updates this log only if the you use the Customer Engagement Loyalty integration. See Customer Engagement Loyalty Integration for background. See the ORCE (Oracle Retail Customer Engagement) Log for more information. |
|
ORCE_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
ORCE_MAX BACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
RICS Log Use this log to review activity related to the pre-order (backorder quantity update) notification message. Note: The system updates this log only if the you generate pre-order (backorder quantity update) notifications as part of the enterprise order integration. See Generating the Backorder Quantity Update Notification Message (PREORDER or ACTPO Periodic Function) for more information. |
|
Defines the level of detail to include in the RICS Log. See Logging Level. |
|
RICS_MAXBACKUP_DAYS |
The number of days to store a backup copy of the RICS Log before it is eligible for deletion. See Archived Logs. To retain a month’s worth of logs, set this field to 30d (default). The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
Narvar Log Use this log to review activity related to the generation of shipment notification emails to customers through the Narvar Integration. |
|
NARVAR_LOG_LEVEL |
Defines the level of detail to include in the Narvar Log. See Logging Level. |
NARVAR_MAXBACKUP_DAYS |
The number of days to store a backup copy of the Narvar Log before it is eligible for deletion. See Archived Logs. To retain a month’s worth of logs, set this field to 30d(default). The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
Use this log to track XML and transactional messages generated or received by Order Management System, with the exception of those captured in the Manifest Log, the Order Log, and the tax messages captured in the Trace Log. You can use this file to confirm that you are receiving or generating messages correctly, to isolate communication problems, or to recover information.
The MQ Log settings in the Logging Properties define the level of detail to include in the log and the number of days to store a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Data security: For data security, Order Management System masks credit card information in this log.
Successful message: A message similar to the following indicates if the transmission was successful:
08:33:54,228 INFO MQ - Out Message:<Message source="OMS" target="external" type="CWPickOut" date_created="2011-08-08" time_created="08:33:53"> <PickHeader transaction_type="A" company="7" pick_nbr="1234" pick_status="M" nbr_labels="2" billing_batch_nbr="1011" date_printed="2011-08-05" time_printed="13:50:46" cart_batch_nbr="18" pick_zone1="A" nbr_lines="1" gen_type="R" merch_amt="10.35" tax_amt="0.52" amt_paid="10.87" total_order_amt="10.87" first_pick="Y" master_carton_nbr="2464" master_carton_pick="N" master_label_order="N" order_nbr="3715" order_shipto_nbr="1" ...
Errors to look for:
A message similar to the following indicates if the transmission failed:
14:42:48,724 ERROR MQ - Cwmqget -Queue Manager: QM_process Queue:ORDERDATAQ Error Message: MQ Object not found
A message similar to the following indicates the queue manager is down and needs to be restarted:
09:08:19,939 ERROR MQ - Cwmqput -Queue Manager: QM_PD3 Queue:PD3.CWDIRECTCPDEV.RETURN_OUT Error Message:null
or
12:51:07,721 INFO MQ - Cwmqput -Queue Manager:QM_PD3 Queue:PD3.CWDIRECTCPDEV.RETURN_OUT Message:
Use this log to track the activity performed in the Order Management System application, such as:
• the processing that occurs in the Order Management System job scheduler
• any errors that occur during email notification processing
• when a user creates, changes, or deletes a record in Order Management System
• any errors that occur during the Customer Engagement Batch Customer and Sales Integrationthe CWEmailOut message
• the processing that occurs by the Long Running Jobs Monitor
The Application Log settings in the Logging Properties defines the level of detail to include in the log and the number of days the system stores a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Email error: The following error indicates an attempt to send an email failed. In this example, the mail server rejected the email request from port 25. This error usually occurs due to virus-checker rejecting the remote mail requests.
13:06:28,586 ERROR APP - Error in CWSendMail.sendMessage(). Could not send email. Here is the exception: javax.mail.SendFailedException: Sending failed; nested exception is: class javax.mail.MessagingException: Could not connect to SMTP host: CWIEX1, port: 12; nested exception is: java.net.SocketException: Software caused connection abort: connect
Use this log to review when a job required user intervention in order to proceed. A job may require user intervention if:
• an error occurred during processing
• the job is used to send transactions to another system and communication failures occur before the transmission completes
The types of job that require user intervention:
• stored value card (activation, balance inquiry, or authorization reversal)
• authorization (batch only, for all card types)
• deposit
The Response Log settings in the Logging Properties defines the level of detail included in the log and the number of days the system stores a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Sample messages:
Message |
Written When |
|---|---|
Deposits - Response required for job. E-Mail sent to:email1@example.com; email2@example.com |
Order Management System generates a Response Required email, indicating a job requires user intervention. In this example, Deposits is the job name and email@example.com is the email address to receive the Response Required email. |
Deposits - Received R response from JSMITH |
A user responded to a response required message at the Reply To Message screen. In this example, Deposits is the job name and JSMITH is the user that responded to the job. |
Deposits - No response after 5 attempts, will retry |
Order Management System reviewed the Response Required table five times to determine if a user responded to the response required message. In this example, Deposits is the job name. |
Deposits - No response after 10 attempts, will retry |
Order Management System reviewed the Response Required table ten times to determine if a user responded to the response required message. In this example, Deposits is the job name. |
Deposits - No response received, default response used |
The number of times to look for a response in the Response Required table has been reached without a response from a user. Order Management System uses the default response for the job. In this example, Deposits is the job name. |
Deposits - Response Required entry not found, default response used |
A user deleted a response required message at the Work with Required Response screen. Order Management System uses the default response for the job. In this example, Deposits is the job name. |
Use this log to review internal messages about Order Management System application processing. Typically, you review this log only if the contents of the Application Log did not help you.
The Trace Log settings in the Logging Properties define the level of detail to include in the log and the number of days to store a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Use this log to review the messages generated between Order Management System and the PC manifest station. You can use this log to confirm that communication between Order Management System and the PC manifest station is working correctly, to isolate communication problems, or to recover information. Also, any errors that occur during processing are written in this log.
The Manifest Log settings in the Logging Properties define the level of detail to include in the log and the number of days to store a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Use this log to review the CWOrderIn and CWORDEROUT messages between an external system and Order Management System as part of the Generic Order Interface (Order API). You can use this log to confirm that communication between the external system and Order Management System is working correctly, to isolate communication problems, or to recover information.
The Order Log settings in the Logging Properties define the level of detail to include in the log and the number of days to store a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Successful message: A message similar to the following indicates if an order message was successful:
12:32:42,483 INFO ORDER - In Message: <Message source="IDC" target="RDC" type="CWORDERIN" resp_qmgr="CWIAS400" resp_q="CWDIRECT.PROMOTION.OUT.10.Q"> <Header company_code="009" order_number="012345-1" payment_only="N" source_code="JMNSRC" response_type="E" order_channel="I" customer_number="123456" pay_incl="Y" order_type="W"> <Payments> <Payment pay_seq_number="1" payment_type="04" cc_type="04" cc_number="************1443" cc_exp_month="12" cc_exp_year="2012" auth_number="manual" auth_date="02112011" /></Payments> <ShipTos><ShipTo shipping_method="98" ship_to_type="2"> <Items><Item quantity="1" item_id="API100"></Item></Items></ShipTo></ShipTos><Coupons> <Coupon /></Coupons></Header></Message>
Errors to look for:
A message similar to the following indicates that the CWOrderIn message passed was not formatted correctly or contained invalid data:
17:21:46,031 INFO ORDER - Out Message:<Message>Invalid XML Message: <Message source="String" target="String" type="CWORDERIN" > <Header company_code="6" rdc_order_number="9967" payment_only="Y" nbr_ship_tos="1" pay_incl="Y" source_code="SOURCE" response_type="E" order_channel="I" sold_to_fname="John" sold_to_lname="Smith" sold_to_address1="10 Example Street" sold_to_city="NATICK" sold_to_state="MA" sold_to_zip="01760" sold_to_country="USA" order_type="I" sold_to_email="eleanor.johnson@example.com" > <Payments> <Payment payment_type="5" cc_number="***5556" cc_exp_month="12" cc_exp_year="12" /> </Payments> </Header> </Message> com.mr.serenade.exception.BOException: OrderInMessageBO.checkDuplicateWebOrder - null </Message>
Use this log to review the messages generated between Order Management System and PayPal when you are using the PayPal Direct Connection Integration. You can use this log to confirm that communication between Order Management System and PayPal is working correctly, to isolate communication problems, or to recover information. Also, any errors that occur during processing are written in this log.
The PayPal Log settings in the Logging Properties define the level of detail to include in the log, and the number of days to store a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Data security: For data security, Order Management System masks credit card information in this log.
Successful message: A message similar to the following indicates if the PayPal deposit transmission was successful:
11:56:55,831 INFO PAYPAL - [Settlement] Transmitted deposit(*PURCH) Processed : AMT=20.94&INVNUM=111-1234&NOTE=PAYPAL+1234&AUTHORIZATIONID=12345678901234567890&COMPLETETYPE=NotComplete&METHOD=DoCapture
Failed message: A failure in the deposit process or errors during processing generate ERROR level messages, such as the following:
11:56:55,831 ERROR PAYPAL - [Settlement] Transmitted deposit(*PURCH) Failure : AMT=20.94&INVNUM=111-1234&NOTE=PAYPAL+1234&AUTHORIZATIONID=12345678901234567890&COMPLETETYPE=NotComplete&METHOD=DoCapture
11:57:06,581 ERROR PAYPAL - [Settlement] Timestamp : 2009-05-08T15:52:55Z
11:57:08,737 ERROR PAYPAL - [Settlement] CorrelationId : 12345abcde
11:57:10,284 ERROR PAYPAL - [Settlement] Error code : 10002
11:57:11,972 ERROR PAYPAL - [Settlement] Short message : Security error
11:57:15,018 ERROR PAYPAL - [Settlement] Long message : Security header is not valid
11:57:17,300 ERROR PAYPAL - [Settlement] Severity code : Error
Setup errors: Errors reading the authorization service or authorization service extended generate ERROR level messages, such as the following:
11:31:04,471 ERROR PAYPAL - [Settlement] Defaults set. Do not process in PayPal 'live' environment
11:31:31,841 ERROR PAYPAL - [Settlement] Exception(s) encountered during Initialization. No Deposit processing performed.
For more information: See PayPal Direct Connection Integration for an overview and the required setup for processing deposit transactions between Order Management System and PayPal using a direct connection.
Use this log to review messages generated between Order Management System and Cybersource when you are using the CyberSource Point-to-Point Integration.
Data security: For data security, Order Management System masks credit card information in this log.
You can use this log to confirm that communication between Order Management System and Cybersource is working correctly, to isolate communication problems, or to recover information. Also, any errors that occur during processing are written in this log.
Setup: The CYB_PAY_LINK_SERVICE_ENABLE_LOGCYB_PAY_LINK_SERVICE_ENABLE_LOGCYB_PAY_LINK_SERVICE_ENABLE_LOG setting in Working with Customer Properties (PROP) defines whether the Cybersource web service logs messages generated between Order Management System and Cybersource when you are using the CyberSource Point-to-Point Integration. Valid values are:
• true = Order Management System writes transactions for the CyberSource Point-to-Point Integration to the Cybersource log.
• false = Order Management System does not write transactions for the CyberSource Point-to-Point Integration to the Cybersource log.
Important: For data security, set this value to false unless you are troubleshooting the Order Management System integration with Cybersource. Once you are done troubleshooting, delete any log files that are created.
The CYB_PAY_LINK_SERVICE_LOG_DIRECTORY property defines the location of the log written by the Cybersource web service API program. For example: /domain/conf/OMSFiles/Integrations/Cybersource/Log/, where domain is the WebLogic domain directory for Order Management System.
To review the file: You can use a text editor to review the log.
For more information: See CyberSource Point-to-Point Integration for an overview and processing details.
Use this log to review the alerts generated by the Job Monitor Status (WJMO) menu option. This log indicates:
• the name of the job monitor associated with the alert
• the name of the job monitor rule associated with the alert
• the action taken for the job monitor rule, such as generating an email or running a periodic process
Note: The system updates this log only if the ALLOW_JOB_ MONITOR and TRACK_ALERTS_IN_LOG settings in Working with Admin Properties (CPRP) are set to Y. These settings should only be set to Y for the application server that allows job scheduling; see How to Schedule a Job.
IntegrationOrder (ChannelAdvisor) Log
Use this log to review activity related to integration with ChannelAdvisor. See ChannelAdvisor Integration Overview for background.
Use this log to review the information submitted to Narvar if you use the Narvar integration to generate shipment confirmation emails.
Setup: Use the following properties to control Narvar logging:
For more information: See Narvar Integration, including the Narvar Order Request Message, for details on the order message to Narvar.
OCDS (Omnichannel Cloud Data Service) Log
Use this log to review activity related to communication with OCDS to import enterprise foundation information, such as merchandise hierarchy, items, prices, and related data.
The OCDSFA periodic function also uses this log.
Setup: Use the following properties to control OCDS logging:
For more information: See Importing Enterprise Foundation Data through Omnichannel Cloud Data Service (OCDS) and Importing Future Available Information (OCDSFA Periodic Function)
ORCE (Oracle Retail Customer Engagement) Log
Use this log to review activity related to the loyalty integration and stored value card integration with Oracle Retail Customer Engagement. The system logs the transactions passed between Order Management System and Oracle Retail Customer Engagement if the Logging Level is DEBUG.
Setup: Use the following properties to control Customer Engagement logging:
For more information: See:
• Customer Engagement Loyalty Integration.
• Customer Engagement Stored Value Card Integration.
OROB (Oracle Retail Order Broker) Log
Use this log, in addition to Order Broker’s logs, to review messages passed between Order Management System and Order Broker as part of the Order Broker Integration.
Use this log to review activity related to the pre-order (backorder quantity update) notification message.
Setup: Use the following properties to control RICS logging:
Sample entries in the RICS log for the pre-order (backorder quantity update) notification:
• Successful message: If the RICS_LOG_LEVEL is set to INFO and the message was sent successfully, the RICS log includes the message contents, and indicates success, for example:
11:59:35,206 INFO RICS - message: Invocation Success
• If the RSB service is down:
ERROR RICS - message: Connection refused to: https://server.us.oracle.com:12345/rms-InventoryBackOrder-AppServiceDecorator/ProxyService/InventoryBackOrderAppServiceProxy?WSDL ConnectException: java.net.ConnectException: Connection refused (Connection refused)
• If web service authentication has not been set up for the RICS Service:
ERROR RICS - message: No Authentication is set up for RICS Service
• If no URL is specified in the RICS Outbound Service URL (M50) system control value when you run the PREORDER periodic function:
ERROR RICS - message: RICS URL string (M50) is not set --> no url in M50
See Generating the Backorder Quantity Update Notification Message (PREORDER or ACTPO Periodic Function) for more information.
________________________________
Contents SCVs Reports XML Messages Glossary
Copyright © 2022, Oracle and/or its affiliates. All rights reserved.
Legal Notices