Log files are useful for troubleshooting and performance improvements within Campaign. Once we had a slow running flowchart at a client, and by reviewing the log file we identified that the actual issue was caused by the network traffic to the database. This helped us to fix the issue and optimize the performance of the flowchart.

One of the more advanced features of Campaign is that it has its own log generation tool from within the application. This means that they are accessible for end-users without having to consult IT Administrators. This blog will provide information about using flowchart log files for analysis and performance improvements.

​The flowchart log provides information about:

  • Potential performance issues with a flowchart run;
  • Identifying flowchart run errors;
  • Capture details of the configuration settings and table catalogs;
  • Capture the actual SQL passed to the database server.

Reading the Log
The flowchart logs are available from the options menu:
Options à view log

When searching for a specific error, it is best to clear the log first, set the required logging options and then run the flowchart again and look at the log file. By following this procedure, only the last run of the flowchart containing the error is shown. This makes it easier to diagnose the error.

Logging Options and Levels
The log file can provide much more detail than you typically would need. Therefore, it may be useful to set the logging level using the Logging options function in the menu. Debug logging options may be useful when contacting Technical Support. Otherwise, this option may definitely produce too much detail. The debugging level usually also decreases the execution speed of the flowchart. So after identifying the root causes, turn it off again. The lowest level of logging is to include only errors, these can be amended with warnings. Information also gives a lot of detail but may be useful when diagnosing issues with the SQL processed on the server, see below.
The logging levels track the different processes executed. They are mostly self-explanatory, and I’ll explain some useful uses below.

Flowchart Log File Structure
To analyze the log files, it helps to understand their structure. The following example illustrates the log file structure.

​The timestamp indicates the time elapsed after starting the process. PID is the process identifier. Sometimes, a hard stop of the flowchart on the server is required. In those rare cases, the PID will be used to find the process that needs to be stopped. Information, Warning or Error relates to the logging level. Category explains what the process was performing, process name is actually the process status and the message body tells the contents of the process, including raw SQL.

Performance Indicators
When flowcharts take very long to execute, or do not seem to finish at all, the log file can indicate where the flowchart takes a long time, or is stuck. Even if the flowchart is still running, it may be useful to open the flowchart log and see what is taking so long. However, this does not allow the log to be cleared and read from again.

When flowcharts take very long, check some more logging levels and check the start and end times of the processes. This should give an indication of what is taking long, for example, the database access, the Campaign server processes, etc.

From looking at the log files, you can determine the time it takes to process events in Campaign.
Session Run-Time  – The time it takes to run a session, for example, a complete flowchart in “production” mode.
Process Run Time –  The time it takes for each process to run.
SQL  –   The time it takes to execute the SQL on the database.
Derived Fields  –  The timing for derived fields to process.

Troubleshooting Performance Procedure

  • Examine the log file;
  • Focus on the process that takes the longest time to execute;
  • Within that process, determine where most of the processing time is occurring:

o   In the query;
o   In the data transfer to the server;
o   In the server processing

Flowchart Run Errors
When the flowchart ends with an error, the best approach is to clear the log, check at least the ERROR logging option – that may be extended with the warning option – then run the flowchart again and check the log. Particularly when checking for errors, the best approach is to start from the bottom of the file and search to the top for the errors. Since the error most likely has happened towards the end of the run, this will be the last item written to the file. Use your browser search function, typically accessed by typing CTRL+F. For better searching and researching the log file, it can be easier to select the complete text (CTRL+A), copy it (CTRL+C) and paste (CTRL+V) it into any other text editor. Notepad on Windows will do, but my personal favorite is Notepad++ (free download from https://notepad-plus-plus.org).

Configuration Details
The configuration details can be read by ticking the log config settings and log table mappings options:

Actual SQL Passed to the Database Server
By checking the  Queries Issued against the Database options, the log file will also display the actual SQL.
Below an example of the resulting queries. Sometimes, the flowchart can be quicker when the SQL is optimized, and executed as raw SQL from within the flowchart than using a process box.

Additional Log Files
Additional log files are located on the server. They require file system access, usually, these rights are available for system administrators. These log files are available from Campaign_home\partitions\partition_name\logs
Typically, when you contact Technical Support, they will ask you to submit the log files. It is already useful to include the flowchart log when opening the support request (or PMR, Problem Management Request). Support will then indicate additional log files if they are required.

Here are some examples of useful logs available in this directory:
Flowchart log – ([campaign_name_ campaign_code_flowchart_name].log) discussed above. Very useful for end-users, can also be beneficial when contacting support.

Campaign Web Application log – (campaignweb.log) The web application log file records events that are generated by the Campaign web application.

Session log – (ac_sess.log) Session information about a flowchart, when the user opens the flowchart before editing it
Also contains information about server connections when flowcharts are executed.

Web Connection log – (ac_web.log) Records information about the user’s connections to the Campaign server.

Campaign Listener log – (unica_aclsnr.log) The listener log contains events generated by Campaign Listener and may exist in several files.

Picture

       Martin Danko
​       Managing Consultant


As a managing consultant at HCL Technologies, Martin is responsible for the delivery of Marketing Software solutions from IBM. He advises leads and influences at strategic as well as the operational level for clients across Europe. Martin combines his knowledge of marketing and technology into practical implementation. His experience stretches across solution definition, business process redesign and systems integration with a focus on CRM, inbound and outbound marketing solutions as well as customer experience.

Marketing Platform, Campaign, Interact, Marketing Operations, Contact Optimization, and Opportunity Detect are trademarks of IBM Corporation, in at least one jurisdiction, and are used under license. 
Comment wrap
Further Reading
article-img
Marketing & Commerce | September 6, 2018
Using Campaign Outbound Triggers
An outbound trigger is the execution of a command, batch file, or script (that is stored on the Campaign Application Server) that takes place after a flowchart or process is run. You can define triggers to perform virtually any action, such as opening an application, sending an email, or running a program.
article-img
Automation | August 27, 2018
Using Campaign Inbound Triggers
This blog will take you through the Inbound Triggers – triggers sent from other applications to Campaign.
article-img
Marketing & Commerce | July 11, 2018
Campaign Execution Best Practices
  The Campaign is the most used tool and the backbone of your marketing ecosystem. Here are the best practice recommended for Campaign users after years of working with this engine. Incorporate the 4 principles of Best Practices into your group Reuse, Organize, Automate and Share. ​ Execution specific Best Practices Create derived fields or custom macros when you need an aggregation of data that doesn’t exist currently on the database. Create control groups at the lowest level of segmentation, and use the random selection functionality provided in the software. When building a new campaign meet as a group and brainstorm the new design before building it.  Then after the campaign is built, meet again as a group to review the design and evaluate the campaign from all three vantage points: Performance, Ease-Of-Use, and Flexibility. Define offer and promotion history so that each discreet contact with a customer can be identified in the database. Use Campaign user attributes to capture more information or create derived fields to support this requirement. Use ‘Check Syntax’ for syntax checking at all times. Use the ‘Summary Tab’ to capture Campaign metadata and descriptive information. Apply suppressions early in the Campaign design process (so that your surviving population is smaller as you progress down the processing chain). To obtain waterfall or cascading counts, use a separate process box for each Select or Segment process, the results can then be displayed with the cell waterfall report. Use the ‘Cell Size Limit’ function to limit output records to particular channels based on constraints. When entering multiple conditions in SELECT and SEGMENT process boxes, enter criteria piece per line and place the AND/OR operators on a separate/newline.  Enter the AND/OR operators in ALL CAPS. Use the ‘General Tab’ to capture comments about the processes you have created. When creating multiple...
Close
Filters result by
Sort:
|