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.
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.
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).
The configuration details can be read by ticking the log config settings and log table mappings options:
By checking the Queries Issued against the Database options, the log file will also display the actual SQL.
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.
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.