Purpose: A variety of logs are available to help troubleshoot Order Management System processing:
• Application Server Logs: 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.
Information related to application server logs:
• 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
- ORCE (Oracle Retail Customer Engagement) Log
- OROB (Oracle Retail Order Broker) Log
Purpose: Use the application server logs to review messages generated by the Order Management System application server at startup, and the messages generated during processing of the Order Management System application.
The log4j.xml file contains configuration settings for logs.
Level of logging: The Threshold setting in the log4j.xml file controls the level of detail included in the application server logs.
Location of file: This file is normally saved on the application server at /domain/conf/log4j.xml, where domain is the WebLogic domain directory for Order Management System.
To edit the file: You can use a text editor to edit the file, being careful not to change any of the settings except those indicated below.
If you make any changes to the log4j.xml file, you must stop and restart Order Management System before the changes take effect.
Setting |
Description |
Append |
This setting controls whether to clear the CWDirect Log file each time the service restarts. If the Append value for the FILE is set to true, the CWDirect Log is saved with a date stamp in the file name when the service restarts, and any subsequent activity is noted in the new CWDirect.log file. For example, if you restart the service on August 27, 2015, the existing log file is renamed CWDirect.log.2015-08-27. To change the setting so that the CWDirect Log is saved under a different file name when the service restarts: 1. Stop Order Management System. 2. Find the FILE entry, such as: <appender name="FILE" class="org.apache.log4j.DailyRollingFileAppender"> - <errorHandler class="org.apache.log4j.helpers.OnlyOnceErrorHandler"/> - <param name="File" value="${openejb.base}/log/CWDirect.log"/> - <param name="Append" value="false"/> 3. Change the Append value to true,so that it reads: <param name="Append" value="true"/> 4. Restart Order Management System. |
Threshold |
The level of detail to include in the application server logs. Valid values: 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. This setting also includes the java class associated with the log message for troubleshooting purposes. 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 log any messages. |
CONSOLE |
It is important to make sure that the CONSOLE entry toward the end of the file is commented out to eliminate needless logging and improve performance. To do so: 1. Stop Order Management System. 2. Find the CONSOLE entry, such as: <root> <appender-ref ref="CONSOLE"/> <appender-ref ref="FILE"/> </root> 3. Comment out the CONSOLE entry, so that it reads: <root> <!-- <appender-ref ref="CONSOLE"/> --> <appender-ref ref="FILE"/> </root> 4. Restart Order Management System. |
Use this log to review messages generated during processing of the Order Management System application.
Name of log: The File setting in the Log4j XML File defines the name of the CWDirect log. You should not change this setting in order to avoid confusion when troubleshooting.
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.
Cleared when? If the Append value in the Log4j XML File is set to false, this file is cleared each time you restart the application; otherwise, if the value is set to true, the file is not cleared. See the Log4j XML File for information on configuring this file.
Special characters in the CWOrderIn message: If you pass a special character 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 Cloud 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 Oracle Retail 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]
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
• ORCE (Oracle Retail Customer Engagement) Log
• OROB (Oracle Retail Order Broker) Log
Location of Order Management System Application Logs
The CW_LOG_DIR setting in Working with Cloud 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 Cloud 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 Cloud 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 30, the system stores a backup copy of the log for 30 days before deleting it.
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 Cloud 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 30. The system deletes any log file older than 30 days. |
|
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 30. The system deletes any log file older than 30 days. |
|
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 30. The system deletes any log file older than 30 days. |
|
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 30. The system deletes any log file older than 30 days. |
|
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 30. The system deletes any log file older than 30 days. |
|
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 30. The system deletes any log file older than 30 days. |
|
Use the OROB.log to review the messages between Order Management System and Oracle Retail Order Broker when you use the Order Broker Integration. You can use this log, in addition to Oracle Retail 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 30. The system deletes any log file older than 30 days. |
|
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 30. The system deletes any log file older than 30 days. |
|
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 30. The system deletes any log file older than 30 days. |
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 30. The system deletes any log file older than 30 days. |
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 30. The system deletes any log file older than 30 days. |
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="2464" 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 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: 25; 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@cware.com; email2@cware.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@cware.com is the email address to receive the Response Required email. |
Deposits - Received R response from BMIRANDA |
A user responded to a response required message at the Reply To Message screen. In this example, Deposits is the job name and BMIRANDA 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="021711-1" payment_only="N" source_code="JMNSRC" response_type="E" order_channel="I" customer_number="13115" 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="Freddie" sold_to_lname="Snare" sold_to_address1="10 Main Street" sold_to_city="NATICK" sold_to_state="MA" sold_to_zip="01760" sold_to_country="USA" order_type="I" sold_to_email="eleanor.roosevelt@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-1754&NOTE=PAYPAL+1754&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-1754&NOTE=PAYPAL+1754&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 : 6e035b0d97c05
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_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 Cloud 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.
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.
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 Oracle Retail Order Broker’s logs, to review messages passed between Order Management System and Oracle Retail Order Broker as part of the Order Broker Integration.
| Reviewing Application Settings in the Jenasys Properties File | Contents | SCVs | Search | Glossary | Reports | Solutions | XML | Index | Monitoring Jobs |
logs OMS 17.1 September 2018 OTN