Title 

Page

webMethods Product Suite Version 7.1 webMethods Logging Guide

Copyright
&  Docu‐
ment ID

Cerebra, Glue, Infravio X‐Broker, Infravio X‐Registry, Infravio, My webMethods Server, My webMethods, webMethods Access, webMethods Administrator, 
webMethods Broker, webMethods Central Configuration, webMethods Dashboard, webMethods Designer, webMethods Developer, webMethods Fabric, 
webMethods Glue, webMethods Infrastructure Data Collector, webMethods Infravio X‐Broker, webMethods Infravio X‐Registry, webMethods Installer, 
webMethods Integration Server, webMethods logo, webMethods Mainframe, webMethods Manager, webMethods Modeler, webMethods Monitor, 
webMethods Optimize for Infrastructure, webMethods Optimize for Process, webMethods Optimize, webMethods Portal, webMethods Process Engine, 
webMethods Servicenet, webMethods Task Engine, webMethods Trading Networks, webMethods Workflow, and webMethods are either registered 
trademarks or trademarks of webMethods, Inc.
Acrobat, Acrobat, and Reader are registered trademarks of Adobe Systems Incorporated.  Amdocs and ClarifyCRM are registered trademarks of Amdocs.  
Ariba is a registered trademark of Ariba, Inc.  BEA, BEA WebLogic Server, Jolt, and Tuxedo are registered trademarks, and BEA WebLogic Platform is a 
trademark of BEA Systems, Inc.  Action Request System, BMC Software, PATROL, and Remedy are registered trademarks of BMC Software, Inc.  BroadVision 
is a registered trademark of BroadVision, Inc.  Chem eStandards and CIDX are trademarks of CIDX, The Chemical Industry Data Exchange.  SiteMinder and 
Unicenter are registered trademarks of CA, Inc.  PopChart is a registered trademark of CORDA Technologies, Inc.  Kenan and Arbor are registered trademarks 
of Alcatel‐Lucent.  Data Connection and SNAP‐IX are registered trademarks of Data Connection Corporation.  D&B and D‐U‐N‐S are registered trademarks of 
Dun & Bradstreet Corporation.  Eclipse is a trademark of Eclipse Foundation, Inc.  Entrust is a registered trademark of Entrust, Inc.  papiNet is a registered 
trademark of the European Union and the United States.  Financial Information eXchange, F.I.X, and F.I.X Protocol are trademarks of FIX Protocol Ltd.  
UCCnet and eBusinessReady are registered trademarks, and 1SYNC and Transora are trademarks of GS1 US.  Hewlett‐Packard, HP, HP‐UX, OpenView, PA‐
RISC, and SNAplus2 are trademarks of Hewlett‐Packard Company.  i2 is a registered trademark of i2 Technologies, Inc.  AIX, AS/400, CICS, ClearCase, DB2, 
Domino, IBM, Informix, Infoprint, Lotus, Lotus Notes, MQSeries, OS/390, OS/400, RACF, RS/6000, SQL/400, S/390, System/390, VTAM, and WebSphere, and 
z/OS are registered trademarks; and Communications System for Windows NT, DB2 Universal Database, IMS, MVS, and SQL/DS are trademarks of IBM 
Corporation.   InnoDB is a trademark of Innobase Oy.  Itanium is a registered trademark of Intel Corporation.  Linux is a registered trademark of Linus 
Torvalds.  W3C is a registered trademark, and X Window System is a trademark of the Massachusetts Institute of Technology.  MetaSolv is a registered 
trademark of Metasolv Software, Inc.  ActiveX, Microsoft, Outlook, Visual Basic, Visual SourceSafe, Windows, Windows NT, and Windows Server are 
registered trademarks of Microsoft Corporation.   Six Sigma is a registered trademark of Motorola, Inc.  Firefox and Mozilla are registered trademarks of the 
Mozilla Foundation.  MySQL is a registered trademark of MySQL AB.  nCipher is a trademark of nCipher Corporation Ltd.   Eclipse is a trademark of Eclipse 
Foundation, Inc.  Entrust is a registered trademark of Entrust, Inc.  papiNet is a registered trademark of the European Union and the United States.  Financial 
Information eXchange, F.I.X, and F.I.X Protocol are trademarks of FIX Protocol Ltd.  UCCnet and eBusinessReady are registered trademarks, and 1SYNC and 
Transora are trademarks of GS1 US.  Hewlett‐Packard, HP, HP‐UX, OpenView, PA‐RISC, and SNAplus2 are trademarks of Hewlett‐Packard Company.  i2 is a 
registered trademark of i2 Technologies, Inc.  AIX, AS/400, CICS, ClearCase, DB2, Domino, IBM, Informix, Infoprint, Lotus, Lotus Notes, MQSeries, OS/390, 
OS/400, RACF, RS/6000, SQL/400, S/390, System/390, VTAM, and WebSphere, and z/OS are registered trademarks; and Communications System for Windows 
NT, DB2 Universal Database, IMS, MVS, and SQL/DS are trademarks of IBM Corporation.  InnoDB is a trademark of Innobase Oy.  Itanium is a registered 
trademark of Intel Corporation.   Teradata is a registered trademark of NCR Corporation. Netscape is a registered trademark of Netscape Communications 
Corporation.  ServletExec is a registered trademark, and New Atlanta is a trademark of New Atlanta Communications, LLC.  SUSE is a registered trademark 
of Novell, Inc.  Appia is a registered trademark and Javelin Technologies is a trademark of NYFIX, Inc.  CORBA is a registered trademark of Object 
Management Group, Inc.  JD Edwards, OneWorld, Oracle, PeopleSoft, Siebel, and Vantive are registered trademarks; and Infranet, PeopleSoft Pure Internet 
Architecture, Portal, and WorldSoftware are trademarks of Oracle Corporation.  Perforce is a trademark of Perforce Software.  JBoss and Red Hat are 
registered trademarks of Red Hat, Inc.  PIP and RosettaNet are trademarks of RosettaNet, a non‐profit organization.   SAP and R/3 are registered trademarks 
of SAP AG.  PVCS is a registered trademark of Serena Software, Inc.  SWIFT and SWIFTNet are registered trademarks of Society for Worldwide Interbank 
Financial Telecommunication SCRL.  SPARC and SPARCStation are registered trademarks of SPARC International, Inc.  BAAN and SSA are registered 
trademarks; and SSA Global is a trademark of SSA Global Technologies, Inc.  EJB, Enterprise JavaBeans, Java, JavaServer, JDBC, JSP, J2EE, Solaris, Sun, and 
Sun Microsystems are registered trademarks; and Java Naming and Directory Interface, JavaServer Pages, SOAP with Attachments API for Java, and SunSoft 
are trademarks of Sun Microsystems, Inc.  Sybase is a registered trademark of Sybase, Inc.  VERITAS is a registered trademark, and VERITAS Cluster Server is 
a trademark of Symantec Corporation.  UNIX is a registered trademark of The Open Group.  Unicode is a trademark of Unicode, Inc.  VeriSign is a registered 
trademark of Verisign, Inc. 
Software AG and all Software AG product names are either trademarks or registered trademarks of Software AG. 
Other product and company names mentioned herein may be the trademarks of their respective owners.
Copyright © 2005‐2007 webMethods, Inc. All rights reserved.
Copyright © 2005‐2007 Software AG and/or its suppliers, Uhlandstrasse 12, 64297 Darmstadt, Germany. All rights reserved.

Document ID: WEBM-LG-71-20070928

 Contents

Contents

About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Server Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Session Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Error Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Guaranteed Delivery Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Service Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Business Process Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Task Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Integration Process Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Document Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Processing Logged Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Viewing Logged Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Archiving or Deleting Logged Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Globalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 2. Logged Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Storing Logged Data in a Database or Flat Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Configure Integration Server to Store Logged Data in Flat Files . . . . . . . . . . . . . . . . . . . . . . . . . 18
Specify the Location for the Flat Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Specify Whether to Write Logged Data Synchronously or Asynchronously . . . . . . . . . . . . . . . . . . . . 20
Tune Asynchronous Logging (Temporary Store Properties) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 3. Server Log Setup and Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Specify Amount and Type of Information to Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Specify Whether to Queue Server Log Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Override Logging Level and Server Log Location for a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
View the Server Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

webMethods Logging Guide Version 7.1 3

 Contents

Chapter 4. Session Log Setup and Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Enable or Disable Session Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
View the Session Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 5. Error Log Setup and Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Enable or Disable Error Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
View the Error Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Chapter 6. Guaranteed Delivery Log Setup and Display . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Enable or Disable Guaranteed Delivery Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
View the Guaranteed Delivery Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Chapter 7. Service Log Setup and Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Globally Enable or Disable Service Logging in Integration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Set Up Customized Service Logging in Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Write User-Defined Messages or Pipelines to the Server Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Write User-Defined Messages to the IS Core Audit Log Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
View the Service Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 8. Setup for All Log Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Change the Log Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Specify the Date and Time Format to Use in Log Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Change the Display Temporarily . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Change the Display Permanently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Display Logged Data in Different Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Send Messages About Critical Issues and Service Failures to Email Addresses . . . . . . . . . . . . . . . . 52
Perform Additional Processing on Log Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

webMethods Logging Guide Version 7.1 4

 About This Guide

About This Guide

This guide explains how to configure webMethods Integration Server server, session, 
error, guaranteed delivery, and service logging, and how to improve logging performance 
or quality of service, as needed, using specific settings. The guide also explains how to 
view logged data. In addition, the guide describes business process, task, integration 
process, and document logging, and points to the webMethods documentation that 
provides more detailed information of those types of logging.

Document Conventions

Convention Description
Bold Identifies elements on a screen.
Italic Identifies variable information that you must supply or change 
based on your specific situation or environment. Identifies terms the 
first time they are defined in text. Also identifies service input and 
output variables.
Narrow font Identifies storage locations for services on the webMethods 
Integration Server using the convention folder.subfolder:service.
Typewriter Identifies characters and values that you must type exactly or 
font messages that the system displays on the console.
UPPERCASE Identifies keyboard keys. Keys that you must press simultaneously 
are joined with the “+” symbol.
\ Directory paths use the “\” directory delimiter unless the subject is 
UNIX‐specific.
[ ] Optional keywords or values are enclosed in [ ]. Do not type the [ ] 
symbols in your own code.

Additional Information
The webMethods Advantage Web site at http://advantage.webmethods.com provides you 
with important sources of information about webMethods products:
Troubleshooting Information. The  webMethods Knowledge Base provides 
troubleshooting information for many webMethods products. 
Documentation Feedback. To provide feedback on webMethods documentation,  go to 
the Documentation Feedback Form on the webMethods Bookshelf.

webMethods Logging Guide Version 7.1 5

 About This Guide

Additional Documentation. Starting with 7.0, you have the option of downloading the  
documentation during product installation to a single directory called 
“_documentation,” located by default under webMethods installation directory. In 
addition, you can find documentation for all webMethods products on the 
webMethods Bookshelf.

webMethods Logging Guide Version 7.1 6

Chapter 1. Concepts

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Server Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Session Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Error Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Guaranteed Delivery Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Service Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Business Process Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Task Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Integration Process Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Document Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Processing Logged Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Viewing Logged Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Archiving or Deleting Logged Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Globalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

webMethods Logging Guide Version 7.1 7

 1. Concepts

Overview
Logging for webMethods products provides important data you need to monitor 
webMethods system activity and correct problems. The webMethods product suite  offers 
the types of logging described below.  

This type of
logging... Provides information about...
Server Operations and errors that occur on Integration Server, such as 
starting of Integration Server subsystems and loading of packages 
belonging to Integration Server or other webMethods products.
Session Sessions opened on Integration Server by clients and Developer 
users.
Error Stack trace information about all errors that occur in Integration 
Server, including exceptions thrown by services.
Guaranteed  Guaranteed delivery transactions. 
delivery
Service Services that run in Integration Server.
Business process Business processes modeled in Designer that run on Integration 
Servers.
Task Tasks designed in Designer that run on My webMethods Server. 
Tasks can be called from business processes or can run as 
standalone tasks.
Integration  Integration processes made up of a chain of services that run on 
process Integration Servers.
Document In doubt, failed, and retries exceeded documents, and documents 
that Broker clients publish or subscribe to on Brokers.

Integration Server maintains this logged data. By default, Integration Server stores most 
of the data in flat files, but Sofware AG highly recommends configuring Integration 
Server to store the data in a database instead. For certain types of logging, you must 
configure Integration Server to store logged data in a database.
This chapter describes each type of logging and the properties you can change to 
customize that type of logging for your environment. It also briefly describes the 
underlying Integration Server mechanism, called the audit subsystem, which performs 
most of the logging. In addition, the chapter lists the default language used for log entries 
and describes the effect of your operating environment and webMethods language packs 
on log entries.

webMethods Logging Guide Version 7.1 8

 1. Concepts

Server Logging
Server logging provides operational and error information from Integration Server’s 
major subsystems, called facilities. For example, the package facility writes server log 
entries when it loads and unloads packages, the flow manager facility writes server log 
entries when it processes a flow service, and HTTP ports write server log entries when 
they receive requests. All facilities write these log entries directly to a log named the server 
log. You specify which facilities you want to write log entries and the amount of detail you 
want each facility to provide.
Other webMethods products, such as Trading Networks and the webMethods EDI 
Modules, also write entries to the server log, and do so automatically. Adapters also write 
entries to the server log. In addition, you can have services write user‐defined messages 
and pipelines to the server log at specified points during their execution.
You can use the information in the server log for general debugging purposes. Below is a 
sample server log.    

{101]2007-07-30 11:52:15 EDT [ISS.0025.0016I] Config File Directory Saved

[100]2007-07-30 11:52:14 EDT [ISU.0000.9999I] InfraDC: calling initRestOfIs
[99]2007-07-30 11:52:14 EDT [ISS.0014.0002C] Initialization completed in 204 seconds.
[98]2007-07-30 11:52:14 EDT [ISS.0025.0025I] Broker Synchronizer initialized
[97]2007-07-30 11:52:13 EDT [ISS.0025.0013I] Cache Sweeper started
[96]2007-07-30 11:52:13 EDT [ISS.0025.0005I] Port Manager started
[95]2007-07-30 11:52:13 EDT [ISS.0025.0036I] Dispatcher started
[94]2007-07-30 11:52:13 EDT [ISS.0098.0027I] PersistenceManager started all Stores
[93]2007-07-30 11:52:13 EDT [ISS.0098.0034I] webM IS RequestReplyHandler starting
execution.
[92]2007-07-30 11:52:13 EDT [ISS.0098.0021I] Exactly Once Trigger Output
Dispatcher started
[91]2007-07-30 11:52:13 EDT [ISS.0098.0021I] Persistent Trigger Output Dispatcher
started
[90]2007-07-30 11:52:13 EDT [ISP.0046.0012I] Enabling HTTP Listener on port 5555
.
.
.

Session Logging
Session logging provides data about sessions that are opened on Integration Server by 
clients and Developer users. You can use session log entries to do the following:
Track when sessions start, their current status, and their duration

Record the client that initiated the session and the Integration Server port on which 
the client connected

webMethods Logging Guide Version 7.1 9

 1. Concepts

Error Logging
Error logging provides data, including stack trace data, about all errors that occur in 
Integration Server. Errors include exceptions thrown by services. You can use error log 
data to debug services. Sample stack trace information is shown below.    
java.lang.NullPointerException
at JpLogger.addScheduleID(JpLogger.java:46)
at java.lang.reflect.Method.invoke(Native Method)
at com.wm.app.b2b.server.JavaService.baseInvoke(JavaService.java:287
at com.wm.app.b2b.server.ServiceManager.invoke(ServiceManager.java:344)
at com.wm.app.b2b.server.comm.DefaultServerRequestHandler.handleMessage
DefaultServerRequestHandler.java:97)
at com.wm.app.b2b.server.HTTPMessageHandler.process(HTTPMessageHandler.
java:167)
at com.wm.app.b2b.server.Dispatch.run(Dispatch.java:204)
at com.wm.util.pool.PooledThread.run(PooledThread.java:105)
at java.lang.Thread.run(Thread.java:498)

Guaranteed Delivery Logging

If you configure the guaranteed delivery capability in Integration Server, guaranteed 
delivery logging provides data about guaranteed delivery transactions. You can use 
guaranteed delivery log entries to do the following:
Track when transactions start and their current status

See the names of guaranteed delivery processes that are running

Track whether the processes completed successfully or failed
For complete information about Integration Server’s guaranteed delivery capability, see 
the webMethods Integration Server Administrator’s Guide.

Service Logging
Service logging provides data about flow and coded (for example, Java) services that run 
in Integration Server. You can use service log entries and data to do the following:
Track when services start, their status, and their duration

Track whether services completed successfully or failed

Record the client that called the service, and the Integration Server port on which the 
client connected
Resubmit services

webMethods Logging Guide Version 7.1 10

 1. Concepts

In Integration Server, you globally enable one type of logging for all services, globally 
disable all logging for all services, or enable customized logging on a service‐by‐service 
basis. If you enable customized logging, you set up the customized logging for specific 
services in Developer. For each service, you can choose the following in Developer:
When to log based on how the service is called. For example, you might choose to log 
only when the service is called by a client request or trigger, as opposed to by other 
services.
On what status to log. For example, you might choose to log only when the service 
fails.
Whether to store the service’s input pipeline and, if so, when. For example, you might 
choose to log the input pipeline only when an error occurs. Storing the input pipeline 
allows you to resubmit the service later if necessary.    

Note: Whether you enable or disable service logging in Integration Server and Developer, 
if error logging is enabled, the audit subsystem always writes error log entries when 
service errors occur. The data includes stack trace data about the errors.

You can augment service logging data using Integration Server built‐in services. The built‐
in services do the following:
Enable services to write user‐defined messages to the server log. You can use this 
feature in any service to post progress messages at certain points in the service’s 
execution (for example, to indicate whether certain segments of code ran 
successfully). You can also use this feature to record the run‐time value of certain 
variables at specified points in the service’s execution so you can see how the values 
changed as the service ran.
Enable services to write the pipeline to the server log at specified points in the 
service’s execution. You can use this feature in any service.
If you are storing logged data in a database, enable services to write user‐defined 
messages to the database. You can use this feature in any service, including services 
that are run by processes. The feature enables you to post progress messages at 
specified points in the service’s execution (for example, to indicate whether certain 
segments of code ran successfully).
You can write user‐defined data regardless of whether you globally enable or disable 
service logging in Integration Server or set up customized service logging in Developer.

webMethods Logging Guide Version 7.1 11

 1. Concepts

Business Process Logging

Business process logging provides data for business processes modeled in Designer that 
run on Integration Servers. You can use business process log entries and data to do the 
following:
Identify business processes

Record the path that business processes took at run time

Track when business processes and business process steps started, changed status, 
and ended
Track whether business processes and steps completed successfully or failed

Resubmit business processes at specified steps
In Designer and My webMethods, you specify the amount and type of data to log for each  
business process model version. In Designer, you can specify process step input and 
output document fields for which to log run‐time values. In My webMethods, you can 
also choose to log process transitions so you can see the path the process took at runtime. 
For instructions on setting up business process logging, see the Designer online help and 
the webMethods Monitor User’s Guide.
Process Engines send logged data for all business processes to the Integration Server audit 
subsystem. The Process Engine is a package installed on every Integration Server that 
runs business process steps. For detailed information on the Process Engine and how it 
logs data, see the webMethods Process Engine User’s Guide.

Task Logging
Tasks are created in Designer and run on My webMethods Server. You can log two types 
of data for tasks:
For all tasks, you can use task log entries to track the following:
When tasks are queued
When users accept or release tasks,  suspend and resume tasks, and complete or 
cancel tasks
Whether tasks completed successfully, failed, or expired
Task Engines send logged data for all tasks to the Integration Server audit subsystem. 
The Task Engine is a feature installed on every My webMethods Server that runs 
tasks. For detailed information on the Task Engine and instructions on setting up task 
logging, see the webMethods Task Engine User’s Guide.

webMethods Logging Guide Version 7.1 12

 1. Concepts

Users perform the actions listed above from the task list in My webMethods. For 
instructions on performing actions on tasks, see the webMethods Task Engine User’s 
Guide.
For tasks that are called from business processes, you can write business process log 
entries. Tasks called from business processes are run as business process steps, so you 
can log the same data for a task that you can log for any other business step (see 
“Business Process Logging”, above). Process Engines log all business process entries.

Integration Process Logging

You can log entries that track the progress and results of integration processes. To do so, 
you have the services that make up the integration process call webMethods Monitor 
built‐in services that create these entries. For complete information, see the webMethods 
Monitor User’s Guide.

Document Logging
There are several types of document logging:
When a trigger is configured for exactly‐once processing and Integration Server 
cannot determine whether the current document is a copy of one the trigger has 
already processed, the audit subsystem logs the document to the logging database as 
an in doubt document. For more information on exactly‐once processing and in doubt 
documents, see the Publish‐Subscribe Developer’s Guide.
If a transient error occurs while Integration Server is publishing, delivering, or 
retrieving a document for a trigger, the audit subsystem logs the document to the 
logging database as a failed document. For more information on failed documents, see 
the Publish‐Subscribe Developer’s Guide.
If Integration Server has tried repeatedly to publish or deliver a document for a 
trigger from its outbound store and failed, the audit subsystem logs the document to 
the logging database as a retries exceeded document. For more information on retries 
exceeded documents, see the Publish‐Subscribe Developer’s Guide.
You can configure your system to log specified documents that Broker clients publish 
or subscribe to on Brokers. The audit subsystem logs those documents to the logging 
database. For more information and detailed instructions, see the webMethods Broker 
Administrator’s Guide.

webMethods Logging Guide Version 7.1 13

 1. Concepts

Processing Logged Data

You can configure the Integration Server audit subsystem to write logged data using 
either of two methods:
Asynchronously. With this method, the audit subsystem first writes logged data to a 
temporary store. In a separate, asynchronous operation, the audit subsystem pulls the 
data from the temporary store and stores the data in your databases or flat files. This 
is the default behavior.
Synchronously. The audit subsystem writes logged data directly to your databases or 
flat files. You can change to synchronous from asynchronous, to improve 
performance.
When writing to flat files, the audit subsystem stores different types of logged data in 
corresponding files; for example, error log entries are stored in error log files. When 
writing to databases, the audit subsystem stores different types of logged data in two 
main database components: the IS Core Audit Log database component and the Process 
Audit Log database component. The figure below shows where the audit subsystem 
stores logged data when Integration Server is configured to write asynchronously to a 
database.    

Task Engine sends log entries for

tasks to audit subsystem

Process Engine sends business process

log entries to audit subsystem

Integration Server
audit
subsystem

audit subsystem writes all logged

data to the temporary store

audit subsystem pulls integration process

and business process log entries from
temporary store temporary store and stores in Process Audit
Log database component

audit subsystem pulls session, error, guaranteed

delivery, and service log entries from temporary store
and stores in IS Core Audit Log database component
IS Core
Process Audit
Audit Log
Log

database

webMethods Logging Guide Version 7.1 14

 1. Concepts

You can change many properties of the temporary store, such as whether to maintain the 
store on disk or in memory. If you are storing logged data in a database, you must change 
some properties; for example, you must set the maximum number of entries the 
temporary store can hold based on factors and constraints in your environment.
For complete information on the IS Core Audit Log and Process Audit Log database 
components, see the webMethods Installation Guide.

Viewing Logged Data

You can use Integration Server Administrator and webMethods Monitor to view logged 
data as indicated below.   

View using Integration Server

Logged Data Administrator? View using Monitor?
Server Yes No

Session Yes No

Error Yes Yes, for logged services, 

documents, and processes
Guaranteed Delivery Yes No

Service All except logged input  Yes

pipelines
Business process No Yes
Task* No No
Integration process No Yes
Document No Yes
*For information on viewing task log entries, see the webMethods Task Engine User’s Guide.

Monitor links related logged data in its display; for example, for a business process or 
business process step, you can see all relevant service, error, and user‐defined message 
entries. Integration Server Administrator does not link related data for you; you must look 
through the individual logs for related data yourself. You can also perform a variety of  
actions from Monitor; for example, if you logged input pipelines for services, you can edit 
the pipelines and resubmit the services. For more information about Monitor, see the 
webMethods Monitor User’s Guide.

webMethods Logging Guide Version 7.1 15

 1. Concepts

Archiving or Deleting Logged Data

You can archive or delete logged data from the IS Core Audit Log and Process Audit Log 
database components. For instructions, see the webMethods Monitor User’s Guide.

Globalization
If a webMethods product is equipped with webMethods language packs and some of 
those language packs correspond to the language used by the operating environment in 
which the product is running, the product writes its log entries in the language used by 
the operating system. If the product is equipped with no language packs or with language 
packs that do not correspond to the language used by the operating system, the product 
writes its log entries in U.S. English.
Suppose your operating environment uses Japanese as its language. You have installed 
language packs including the Japanese Language Packs on Integration Server, so 
Integration Server stores its own log entries in Japanese. You have not installed the 
Japanese Language packs on Trading Networks, so Integration Server stores Trading 
Networks’ log entries in U.S. English.    

Note: Even if no language packs are installed on the webMethods product and the product 
is using U.S. English, Integration Server might store log entries from external sources, 
such as database drivers or adapter resources, in the language used by the operating 
environment in which the product is running.

webMethods Logging Guide Version 7.1 16

Chapter 2. Logged Data Storage

Storing Logged Data in a Database or Flat Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Specify Whether to Write Logged Data Synchronously or Asynchronously . . . . . . . . . . . . . . . . 20

Tune Asynchronous Logging (Temporary Store Properties) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

webMethods Logging Guide Version 7.1 17

 2. Logged Data Storage

Storing Logged Data in a Database or Flat Files

By default, Integration Server stores logged data in flat files, but Sofware AG highly 
recommends that you configure Integration Server to store the data in a database instead. 
Typically, you would only use flat file storage if you lack the resources to purchase, install, 
and manage a database.   

Note: The server log is always stored in flat files. You cannot store it in a database.

The benefits of using a database are as follows:
You can use Monitor, which allows you to view document, business process, and 
integration process log entries, as well as perform a variety of actions not otherwise 
available. For information on the benefits of using Monitor, see “Viewing Logged 
Data” on page 15.
Storing logged data in a database improves logging performance. When you use a 
database, multiple logging threads can write data from Integration Server’s temporary 
store to the database simultaneously. When you use flat files, only one logging thread 
at a time can write data to each file.
You can use facilities in your database to control the length of time the data is 
retained. When you store logged data in flat files, you must delete the files manually 
when you no longer need them.
You must either store the IS Core Audit Log and Process Audit Log to a database or to flat 
files. You cannot store one log in a database and the other in flat files.
The section below explains how to configure Integration Server to store logged data in flat 
files. For instructions on configuring Integration Server to store logged data in a database, 
see the webMethods Installation Guide.

Configure Integration Server to Store Logged Data in Flat

Files
By default, Integration Server stores the logged data listed in the table below in flat files in 
the Integration Server_directory\logs directory. Integration Server creates new flat files each 
day if there are log entries on that day, where the end of each day is midnight (12 a.m.). 
For example, if the first error for a day occurs at 1 a.m., Integration Server creates the new 
error log flat file for that day at 1 a.m. If the first error for a day occurs at 3:15 p.m., 
Integration Server creates the new error log flat file for that day at 3:15 p.m. If no errors 
occur during a day, Integration Server does not create a new error log flat file for that day. 

webMethods Logging Guide Version 7.1 18

 2. Logged Data Storage

In the file names below, yyyymmdd identifies the date on which Integration Server created 
the flat file.    

Logged Data File Name

Server server.log.yyyymmdd
Session sessionyyyymmdd.log
Service audityyyymmdd.log
Error erroryyyymmdd.log
Guaranteed  txinyyyymmdd.log (inbound transactions log file, on Integration Server 
delivery host machine)
txoutyyyymmdd.log (outbound transactions file, on the client host 
machine)

Important! The guaranteed delivery function has a client component 
and a server component. The server component runs on Integration 
Server. The client component can run on another Integration Server or 
can be a standalone Java program that uses the guaranteed delivery 
TContext API. In the latter case, the log file written to by the 
guaranteed delivery function is determined by the Java property 
watt.tx.logfile. Each time you start the client component, specify this 
property using the ‐D option on the command line:

-Dwatt.tx.logfile=logs/MyTX.log

For example:

\utils\jdk1.3.1\bin\java -mx64M -ms64M

-Dwatt.tx.logfile=logs/MyTX.log
-classpath .;.\client.jar com.wm.app.b2b.client.TCTest -i

Specify the Location for the Flat Files

You can have Integration Server store the flat files in a directory other than the default. For 
example, if you want to save room on the Integration Server host machine, you might 
change the file storage location to a directory on a different machine.

To store log files in a different directory:

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of the Integration Server 
configuration properties you can change using this method.
2 Select the check box next to the watt.debug.logfile property.

webMethods Logging Guide Version 7.1 19

 2. Logged Data Storage

3 Click Save Changes. Integration Server Administrator displays the property in the 
Extended Settings box.
4 Click Edit Extended Settings. In the Extended Settings box, set the property as follows:
watt.debug.logfile=fully qualified path to server, session, service,
and error log file directory

5 Click Save Changes, then restart Integration Server.

Specify Whether to Write Logged Data Synchronously or

Asynchronously
By default, the audit subsystem first writes logged data to a temporary store. In a 
separate, asynchronous operation, the audit subsystem pulls the data from the temporary 
store and stores the data in your database or flat files. You can choose to improve 
performance by having the audit subsystem write logged data directly (that is, 
synchronously) to your database or flat files.   

Important! If you choose to write synchronously, and Integration Server unexpectedly shuts 
down or another unexpected disruption occurs, you might lose logged data.

To specify whether to write logged data synchronously or asynchronously:

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of the Integration Server 
configuration properties you can change using using this method.
2 Select the check box next to the watt.server.auditSync property.
3 Click Save Changes. Integration Server Administrator displays the property in the 
Extended Settings box.
4 Click Edit Extended Settings. In the Extended Settings box, set the property to true if you 
want to write logged data synchronously, or to false if you want to write logged data 
asynchronously, using the temporary store.
5 Click Save Changes, then restart Integration Server.

webMethods Logging Guide Version 7.1 20

 2. Logged Data Storage

Tune Asynchronous Logging (Temporary Store Properties)

By default, the Integration Server audit subsystem writes all session, service, error, 
guaranteed delivery, document, and process logged data asynchronously, using a 
temporary store. You can tune the properties for the temporary store.

To tune asynchronous logging (temporary store properties):

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of Integration Server 
configuration properties you can change using this method.
2 Select check boxes next to properties as follows:    

Select this
To change this... From the default... Reasons to change... property...
Minimum number of threads to use  1 thread Typically not  watt.server.
concurrently to write logged data to the  necessary to  auditMinPool
temporary store and to pull logged data  change.
from the temporary store and write it to a 
database or flat files. For example, 1 
thread means the audit subsystem uses 
at least 1 thread to write logged data to 
the temporary store, and at least 1 thread 
to pull logged data from the store.
Maximum number of threads to use  10 threads Improve  watt.server.
concurrently to write logged data to the  performance. If  auditMaxPool
temporary store and to pull logged data  storing logs in a 
from the temporary store and write it to a  database, 
database or flat files. For example, 10  coordinate with the 
threads mean the audit subsystem uses  maximum database 
up to 10 threads to write logged data to  connections value.
the temporary store, and up to 10 threads 
to pull logged data from the store.
Number of log entries for each thread to  100 entries Customize to your  watt.server.
pull from the temporary store and store,  environment. auditFetchSize
as a batch, in a database or flat files.
If storing logged data in a database,  3 retries Improve quality of  watt.server.
maximum number of times to retry  service. auditRetryCount
writing a log entry to the database.

webMethods Logging Guide Version 7.1 21

 2. Logged Data Storage

Select this
To change this... From the default... Reasons to change... property...
Whether to maintain the temporary store  Disk; file stored  Improve  watt.server.audit
on disk or in memory. in Integration  performance or  Guaranteed
Server_directory quality of service.
\audit\data 
directory
Maximum number of log entries the  100,000 entries Customize to your  watt.server.audit
temporary store can hold. environment. If  Threshold
storing logs in a 
database, 
coordinate with 
database 
connection values.
If maintaining the temporary store on  10 megabytes Adjust the size of  watt.server.audit
disk, space allocation for the temporary  the temporary store  DBSize
store file. file for your 
environment.
If maintaining the temporary store on  Integration  Save room on  watt.server.audit
disk, directory to which to write the  Server_directory Integration Server  Dir
temporary store file. \audit  host machine.
directory

3 Click Save Changes. Integration Server Administrator displays the selected properties 
in the Extended Settings box.
4 Click Edit Extended Settings. In the Extended Settings box, set the properties as follows:
watt.server.auditMinPool=minimum concurrent threads to write data
to/pull data from temporary store
watt.server.auditMaxPool=maximum concurrent threads to write data
to/pull data from temporary store

The audit subsystem has its own thread pool, so the setting of this property does 
not affect the performance of other Integration Server operations.
If you are storing logged data in a database, set this property equal to the total 
maximum number of connections you specify for the connection pools for that 
database, minus one for Monitor’s connection. If you do not set this property 
correctly, the temporary store could fill to capacity, and subsequent log entry 
requests and pending services would block. If such a situation occurs, the audit 
subsystem tries to write the oldest pending log entry up to the number of times 
specified on the watt.server.auditRetryCount property. If it still cannot write the 
log entry to the temporary store, the audit subsystem writes the entry to the 
server log instead. Log entry requests and services continue to block until space 
again becomes available in the temporary store.

webMethods Logging Guide Version 7.1 22

 2. Logged Data Storage

watt.server.auditFetchSize=batch size of log entries for each

thread to pull from temporary store

Set this property to a size that accommodates your system’s average volume for 
log entries. Also consider the watt.server.auditMaxPool property setting and your 
JVM’s heap size. If you are storing logged data in a database, factor in database 
performance and the amount of bandwidth available through your network to the 
database.
watt.server.auditRetryCount=maximum times to retry write to
database

If you are storing logged data in a database and the temporary store fills to 
capacity, the audit subsystem tries to write the oldest pending log entry up to the 
number of times specified on this property. Set this property based on the degree 
to which you require log entries to be stored in the database. If the audit 
subsystem cannot write the log entry to the temporary store after the specified 
number of retries, it writes the entry to the server log instead.
watt.server.auditGuaranteed={true|false}

To maintain the temporary store on disk, set the property to true. To maintain the 
temporary store in memory, set the property to false.
Maintaining the store on disk provides better logging quality of service, while 
maintaining the store in memory provides better logging performance. However, 
if you choose to maintain the temporary store in memory and Integration Server 
shuts down abnormally, all information in the temporary store will be lost.
Make sure you have enough disk space or memory available to handle your 
average volume for log entries.
watt.server.auditThreshold=maximum entries in temporary store

Specify this value in thousands. For example, if you want to set the maximum 
entries to 200,000, specify 200.
Set this property to a size that accommodates your system’s average volume for 
log entries. If your logging volume has sudden spikes, the audit subsystem can 
usually catch up by writing the pending entries during lulls. Make sure the 
Integration Server host machine has enough physical memory and RAM to 
accommodate the largest possible size of the temporary store as specified on this 
property, as well as the requirements of other applications on the Integration 
Server.
If you are storing logged data in a database, the audit subsystem’s insertion of 
logged data into the database is constrained by the database’s availability and 
connections limit. If the audit subsystem cannot pull entries from the temporary 
store and write them to the database quickly enough, the temporary store could 
fill to capacity, and subsequent log entry requests and pending services would 
block. Coordinate the setting of this property with the watt.server.auditFetchSize 

webMethods Logging Guide Version 7.1 23

 2. Logged Data Storage

property and your database connection values to make sure the temporary store 
is emptied efficiently.
Integration Server displays messages that warn you when the temporary store is 
about to or has filled to capacity. Integration Server also displays messages that 
tell you when space has again become available in the temporary store and the 
audit subsystem has resumed storing log entries in the database or flat files.
watt.server.server.auditDBSize=space allocation for temporary store
file

If you store the temporary store on disk, the audit subsystem creates a file of the 
size you specify on this property in the Integration Server_directory\audit\data 
directory under the name AuditStore.data0000000. Specify the value in 
megabytes.
If the audit subsystem cannot pull entries from the temporary store quickly 
enough, the temporary store file’s capacity might be insufficient to hold the 
pending entries. In this case the audit subsystem creates a second file named 
AuditStore.data0000001 that is the same size as the first. If the second file’s 
capacity becomes insufficient, the audit subsystem creates a third file named 
AuditStore.data0000002, and so on. These extra files continue to exist even after 
all pending requests have been pulled, consuming space on your disk.
If the audit subsystem creates the extra files because of an unusual event (for 
example, your database was down unexpectedly for a long period of time), you 
should free up disk space by removing the extra files when the event is over and 
your system has returned to normal. To do so, change the value on this property 
by increasing it slightly. The audit subsystem will create a new temporary store 
file of the specified size and delete all the old files.
If you find that you are removing extra files and the audit subsystem is recreating 
them on a regular basis, however, it is a sign that you need more temporary store 
space. Increase the value on this property as much as necessary. The audit 
subsystem will create a new temporary store file of the specified size, copy all 
pending requests from the old files to the new file, and delete all the old files. You 
should also review the other temporary store properties discussed in this chapter 
to make sure they are set for the most efficient processing of logged data.
watt.server.auditDir=fully qualified path to temporary store
directory

If you are storing the temporary store on disk and you want to save room on the 
Integration Server host machine, you might set this location to a directory on a 
remote machine.
5 Click Save Changes, then restart Integration Server.

webMethods Logging Guide Version 7.1 24

Chapter 3. Server Log Setup and Display

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Specify Amount and Type of Information to Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Specify Whether to Queue Server Log Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Override Logging Level and Server Log Location for a Session . . . . . . . . . . . . . . . . . . . . . . . . . 28

View the Server Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

webMethods Logging Guide Version 7.1 25

 3. Server Log Setup and Display

Overview
Server logging provides operational and error information from Integration Server’s 
major subsystems, called facilities, and from facilities for individual products that are 
installed on Integration Server. The facilities write all server log entries directly to a log 
named the server log.
By default, all facilities write to the server log, and the facilities write log entries about 
critical, error, warning, informational, and debug‐related situations. You can have only 
selected facilities write to the log, and you can increase or decrease the amount of data the 
facilities provide. This flexibility is useful for troubleshooting. For example, you might 
temporarily increase the level of detail written to the server log to help uncover the cause 
of an Integration Server error or performance problem, and return to a lower level once 
the problem is resolved. You can also override the amount of information to include in the 
server log for a particular Integration Server session.
By default, Integration Server queues log entries written by its facilities in memory, then 
uses a background thread to write them to the server log. You can change that property so 
that facilities write directly to the server log. Using a background thread improves 
Integration Server performance, but writing directly causes the entries to appear in the 
server log more quickly.
Integration Server always writes server log entries to flat files; you cannot store the server 
log in a database. You can override the location of the server log files for a particular 
session.

Specify Amount and Type of Information to Include

To specify the amount and type of information to include in the server log:

1 In Integration Server Administrator, go to the SettingsLogging page. The Loggers area 
lists Integration Server and products that are installed on Integration Server, and the 
facilities for each of these. To see the facilities and their current logging levels, open 
the tree.
2 Click Edit Logging Settings. By default, all products inherit the logging level of the 
Default node. Inherited values are shown in grey text. When you explicitly change the 
logging level for a product or facility, that level overrides the Default node level. You 
can take these actions:
Change the level for the Default node. To do so, click the level to use in the Logging
Level list for the Default node. Integration Server Administrator resets all products 
and facilities that inherit from the Default node to the new level.
Change the level for a particular product from the Default node level. To do so, 
click the level to use in the Logging Level list for the product node. Integration 

webMethods Logging Guide Version 7.1 26

 3. Server Log Setup and Display

Server Administrator resets all facilities that inherit their values from the product 
to the new level.
Change the level for a particular facility. To do so, click the level to use in the 
Logging Level list for the facility.
If you change a level and later want it to inherit from its parent node again, reset the 
level to the level of the parent node.
The logging levels are described below. Each logging level includes the indicated type 
of message plus all messages from the levels above it (for example, the Warn level 
includes Fatal, Error, and Warn messages).        

Level Integration Server records these entries... Examples

Fatal Failures that end operations in such a way  Product cannot read its 
that the operations cannot successfully  configuration file and 
continue without user intervention. Failure is  has no default settings
VERY likely to affect other operations or 
products.
Error Same as Fatal, except that existing error  Business process step 
handling renders the failure unlikely to affect  failed due to a service 
other operations or products. error caused by bad 
input data
Warn Problems that do not end operations, or  Multiple registered JMX 
unexpected or unusual conditions that might  servers were discovered 
signal impending failure. when only one is needed
Info Success of an event that you need to know  Package loaded, or  
about. connection pool 
initialized
Debug Code‐level statements recording unusual  Expected an object to be 
conditions or decisions that might lead to  initialized but it is not, or 
errors. hash table is empty
Trace Code‐level statements recording program  Method entry/exit, or 
flow and state during normal execution. local and global object 
state
Off No information for the product or facility is  
written to the server log.

Important! Recording more information consumes more system resources.

3  Click Save Changes.

webMethods Logging Guide Version 7.1 27

 3. Server Log Setup and Display

Specify Whether to Queue Server Log Entries

By default, Integration Server queues log entries written by its facilities in memory, then 
uses a background thread to write them to the server log. Because only one facility can 
write to the server log at one time, queuing the entries improves performance by making 
writing asynchronous. However, if Integration Server shuts down abnormally, all log 
entries in the queue will be lost. For better quality of service, do not queue the entries. 
However, each facility will have to wait as long as necessary to write its entry to the server 
log, so Integration Server performance might be affected.  

To specify whether to queue server log entries:

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of the Integration Server 
configuration properties you can change using this method.
2 Select the check box next to the watt.server.log.queued property.
3 Click Save Changes. Integration Server Administrator displays the property in the 
Extended Settings box.
4 Click Edit Extended Settings. In the Extended Settings box, set the property to true if you 
want to queue server log entries or to false if you do not want to queue server log 
entries.
5 Click Save Changes, then restart Integration Server.

Override Logging Level and Server Log Location for a Session

You can override the logging level property setting, server log location, or both for a 
particular Integration Server session by starting Integration Server from the command line 
with certain options.
You can also change the default location of the server log files. For instructions, see 
“Specify the Location for the Flat Files” on page 19.  

To override log level and server log location for a session:

1 Open a command window and go to the Integration Server installation directory.
2 Start Integration Server by entering this command:   

System Command
Windows bin\server.bat [-debug level] [-log {filename | none}]

UNIX bin/server.sh [-debug level] [-log {filename | none}]

webMethods Logging Guide Version 7.1 28

 3. Server Log Setup and Display

Options are shown below.      

Option Description
level Amount of information to record for all products and facilities listed 
on the SettingsLogging page for this session. For possible values, see 
“Specify Amount and Type of Information to Include” on page 26.
For this session only, this option overrides the values specified on the 
SettingsLogging page and on the watt.debug.level property.
filename Fully qualified path to the file in which to write the server log for this  
session.
For this session only, this option overrides the value specified on the 
watt.debug.logfile property.
none Displays the server log on your console. Integration Server records a 
timestamp with no other information in the server log file for this  
session.
For this session only, this option overrides the value specified on the 
watt.debug.logfile property.

View the Server Log

In Integration Server Administrator, go to the LogsServer page to view the server log. By 
default, Integration Server uses this format for server log entries:
yyyy‐mm‐dd hh:mm:ss time_zone [facility_code] message 
To see the facility that matches each facility code, go to the SettingsLogging page in 
Integration Server Administrator.
By default, Integration Server Administrator displays the most recent entries in the log. 
You can change various aspects of the display, including the date/time format (see 
“Change the Log Displays” on page 50). Integration Server gets the time zone value from 
your JVM.
Integration Server 7.1 offers a new format for server log entries that you can switch to:
WEBMETHODS: host:port ‐ (product_code) [facility_code] yyyy‐mm‐dd hh:mm:ss.nanoseconds 
time_zone logging_level_code: message 
Product codes are as follows:    
Code Product
BA Basis (Integration Server subcomponents)
ITD Developer

webMethods Logging Guide Version 7.1 29

 3. Server Log Setup and Display

Code Product
ITU Developer utility classes
EDICOR EDI Module
EDIINT EDIINT
ISS or ISC Integration Server
LGU Logging Utility
PRT Process Engine
MON Monitor
TNS Trading Networks

The logging levels and codes are Fatal (C), Error (E), Warn (W), Info (I), Debug (D), and 
Trace (T). Your logging level setting determines the types of messages you see in the server 
log.   

To change the format of server log entries:

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of the Integration Server 
configuration properties you can change using this method.
2 Select the check box next to the watt.debug.layout property.
3 Click Save Changes. Integration Server Administrator displays the property in the 
Extended Settings box.
4 Click Edit Extended Settings. In the Extended Settings box, set the property to legacy if 
you want to use the default format or to new if you want to use the 7.1 format.
5 Click Save Changes, then restart Integration Server.

webMethods Logging Guide Version 7.1 30

Chapter 4. Session Log Setup and Display

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Enable or Disable Session Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

View the Session Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

webMethods Logging Guide Version 7.1 31

 4. Session Log Setup and Display

Overview
Session logging provides data about sessions that are opened on Integration Server. By 
default, session logging is enabled, but you can disable it.

Enable or Disable Session Logging

To enable or disable session logging:

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of Integration Server 
configuration properties you can change using this method.
2 Select check box next to the watt.server.auditlog.session property.
3 Click Save Changes. Integration Server Administrator displays the selected property in 
the Extended Settings box.
4 Click Edit Extended Settings. In the Extended Settings box, set the 
watt.server.auditLog.session property to true to enable session logging, or to false 
to disable session logging.
5 Click Save Changes, then restart Integration Server.

View the Session Log

In Integration Server Administrator, go to the LogsSession page to view the session log. 
The fields in the session log are listed below.   

Column Details
Timestamp Date and time the entry was written to the log.
Server Id Integration Server on which the session occurred and port on 
which the client connected. The ID can be DNSname:port or 
IPaddress:port.
User Id Integration Server user name under which the client connected for 
the session.
Client IP IP address of the machine from which the client request was 
submitted. The word “system” appears for session requests from 
Integration Server for operations such as running a scheduled 
service or refreshing the display. 
Session State Current status of the session (Started, Expired, or Ended).
RPCs Number of services the client has called so far during the session.

webMethods Logging Guide Version 7.1 32

 4. Session Log Setup and Display

Column Details
Age Duration of the session, in milliseconds.
Session ID A string the server generates to identify each session uniquely. 

By default, Integration Server Administrator displays the most recent entries in the log. 
You can change various aspects of the display (see “Change the Log Displays” on 
page 50).

webMethods Logging Guide Version 7.1 33

 4. Session Log Setup and Display

webMethods Logging Guide Version 7.1 34

Chapter 5. Error Log Setup and Display

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Enable or Disable Error Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

View the Error Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

webMethods Logging Guide Version 7.1 35

 5. Error Log Setup and Display

Overview
Error logging provides data, including stack trace data, about all errors that occur in 
Integration Server. By default, error logging is enabled, but you can disable it.

Enable or Disable Error Logging

To enable or disable error logging:

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of Integration Server 
configuration properties you can change using this method.
2 Select the check box next to the watt.server.auditLog.error property.
3 Click Save Changes. Integration Server Administrator displays the selected property in 
the Extended Settings box.
4 Click Edit Extended Settings. In the Extended Settings box, set the 
watt.server.auditLog.error property to true to enable error logging, or to false to 
disable error logging.
5 Click Save Changes, then restart Integration Server.

View the Error Log

In Integration Server Administrator, go to the LogsError page to view the error log. The 
fields in the error log are listed below.   

Column Details
Timestamp Date and time the entry was written to the log.
Service Name Name of the service in which the error occurred.
Error Message Message that describes the error that occurred. 
Stack Trace Trace that shows the call sequence leading to the error. To expand 
the display of stack trace data, select the Expand Stack Trace Data 
check box in the Log display controls area and click Refresh.
Root Context Context information Monitor uses to connect related entries from 
Parent Context different logs.
Current Context

webMethods Logging Guide Version 7.1 36

 5. Error Log Setup and Display

By default, Integration Server Administrator displays the most recent entries in the log. 
You can change various aspects of the display (see “Change the Log Displays” on 
page 50).
For information about viewing error log entries in Monitor, see the webMethods Monitor 
User’s Guide.

webMethods Logging Guide Version 7.1 37

 5. Error Log Setup and Display

webMethods Logging Guide Version 7.1 38

Chapter 6. Guaranteed Delivery Log Setup and Display

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Enable or Disable Guaranteed Delivery Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

View the Guaranteed Delivery Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

webMethods Logging Guide Version 7.1 39

 6. Guaranteed Delivery Log Setup and Display

Overview
Guaranteed delivery logging provides data about guaranteed delivery transactions in 
Integration Server. By default, guaranteed delivery logging is enabled, but you can disable 
it. The audit subsystem writes guaranteed delivery log entries to two logs, one for 
inbound transactions and one for outbound transactions.

Enable or Disable Guaranteed Delivery Logging

To enable or disable guaranteed delivery logging:

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of Integration Server 
configuration properties you can change using this method.
2 Select the check box next to the watt.server.auditLog.gd property.
3 Click Save Changes. Integration Server Administrator displays the selected property in 
the Extended Settings box.
4 Click Edit Extended Settings. In the Extended Settings box, set the watt.server.auditLog.gd 
property to true to enable guaranteed delivery logging, or to false to disable 
guaranteed delivery logging.
5 Click Save Changes, then restart Integration Server.

View the Guaranteed Delivery Log

In Integration Server Administrator, go to the LogsGuaranteed Delivery page to view the 
guaranteed delivery log. The fields in the guaranteed delivery log are listed below.      

Column Details
Timestamp Date and time the entry was written to the log..
Status Current status of the transaction (Start or Stop).
Message Name of the guaranteed delivery process that is running.
Error Message If the transaction failed, message that describes the error that 
occurred.
Root Context Context information Monitor uses to connect related entries from 
Parent Context different logs.
Current Context

webMethods Logging Guide Version 7.1 40

 6. Guaranteed Delivery Log Setup and Display

By default, Integration Server Administrator displays the most recent entries in the 
inbound guaranteed delivery transactions log. You can switch to the log entries in the 
outbound transactions log by clicking View Guaranteed Delivery Outbound Log. You can 
change various aspects of the display (see “Change the Log Displays” on page 50).

webMethods Logging Guide Version 7.1 41

 6. Guaranteed Delivery Log Setup and Display

webMethods Logging Guide Version 7.1 42

Chapter 7. Service Log Setup and Display

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Globally Enable or Disable Service Logging in Integration Server . . . . . . . . . . . . . . . . . . . . . . . 44

Set Up Customized Service Logging in Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Write User-Defined Messages or Pipelines to the Server Log . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Write User-Defined Messages to the IS Core Audit Log Database . . . . . . . . . . . . . . . . . . . . . . . 47

View the Service Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

webMethods Logging Guide Version 7.1 43

 7. Service Log Setup and Display

Overview
Service logging provides data about flow and coded (for example, Java) services that run 
in Integration Server. By default, logging is globally enabled in Integration Server on a 
service‐by‐service basis for all services, but no customized logging is set up for any service 
in Developer. Customized logging specifies the following for a service:
When to log based on how the service is called. For example, you might choose to log 
only when the service is called by a client request or trigger, as opposed to by other 
services.
On what status to log. For example, you might choose to log only when the service 
fails.
Whether to store the service’s input pipeline and, if so, when. For example, you might 
choose to log the input pipeline only when an error occurs. Storing the input pipeline 
allows you to resubmit the service later if necessary.
You can change the global settings in Integration Server. You can set up one type of 
logging for all services, or you can disable logging for all services. If you enable service‐
by‐service logging in Integration Server, you can set up customized logging for specific 
services in Developer.
You can augment service logging data by using Integration Server built‐in services to 
write user‐defined messages to the server log or to the IS Core Audit Log database.

Note: Entries in the audit log identify the Integration Server that executed the service. The 
Integration Server ID always uses the primary Integration Server port, even if a service 
execute using another (non‐primary) Integration Server port.

Globally Enable or Disable Service Logging in Integration

Server

To globally enable or disable service logging:

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of the Integration Server 
configuration properties you can change using this method.
2 Select the check box next to the watt.server.auditLog property.
3 Click Save Changes. Integration Server Administrator displays the property in the 
Extended Settings box.

webMethods Logging Guide Version 7.1 44

 7. Service Log Setup and Display

4 Click Edit Extended Settings. In the Extended Settings box, set the watt.server.auditLog 

property as follows:        

If you want to... Set to...

Disable service logging globally. You cannot override this setting in  off
Developer for any service.
Enable service‐by‐service logging. You must set up the exact logging  perSvc
you want for specific services in Developer.
Have the audit subsystem automatically write start and failure or  brief
success log entries for every service every time the service is called, 
either directly (top‐level) or by another service (nested). You cannot 
override this setting in Developer for any service.
Have the audit subsystem automatically write start and failure or  verbose
success log entries and the input pipeline every time the service is called, 
either directly (top‐level) or by another service (nested). You cannot 
override this setting in Developer for any service.

Sofware AG recommends using the perSvc option. Use the brief or verbose option only 
in a development environment, when performing an extensive debugging effort.
5 Click Save Changes, then restart Integration Server.

Set Up Customized Service Logging in Developer

If you set the watt.server.auditLog property to perSvc, set up customized logging as 
required for services in Developer. For each service, you can choose the following on the 
Developer Properties panel, under Audit:
Whether to log and, if so, when, as follows:
Every time the service is called, whether by a client request, trigger, or another 
service
Only when the service is called by a client request or a trigger (that is, when the 
service is a top‐level service)
At what statuses in the service’s execution to log, as follows:
Only when the service fails
When the services fails or completes successfully
When the service starts and fails or completes successfully

webMethods Logging Guide Version 7.1 45

 7. Service Log Setup and Display

Whether to store the service’s input pipeline and, if so, when, as follows:
Only when an error occurs
Always
For complete information on working with services, see the webMethods Developer User’s 
Guide.
To improve service logging performance, do the following:
Set up customized logging for top‐level services only. Avoid logging nested services.

Log on service failure or log on service failure or successful completion. Only choose 
to log on service failure or success and start when you need the greatest possible 
quality of service.
Store the input pipeline only for top‐level services and only when absolutely 
necessary. It is usually sufficient to store the pipeline on failure only. Remove all 
unnecessary data from the pipeline to minimize the volume of data to store.
The business process log entries that the Process Engine can write for business process 
steps that run services (that is, business process step start and successful completion 
or failure log entries) convey the same information as the service log entries you can 
write for services. In addition, the Process Engine can store the input pipeline for 
services that are run by business process steps. To improve logging performance, 
coordinate logging for such services to avoid logging the same information twice.   

Note: When coordinating logging, keep in mind that when a service is run by a 
business process step, it is actually called by a wrapper service, making it a nested 
service (as opposed to a top‐level service).

Write User-Defined Messages or Pipelines to the Server Log

To have a service write user‐defined messages to the server log, you use the Integration 
Server built‐in service pub.flow:debugLog. You can call the pub.flow:debugLog service from any 
service to post progress messages at certain points in the service’s execution (for example, 
to indicate whether certain segments of code ran successfully). You can also use the 
pub.flow:debugLog service to record the run‐time value of specific variables at certain points 
in the service’s execution so you can see how the values changed as the service ran.
To have a service write the pipeline to the server log at specified points in the service’s 
execution, you use the Integration Server built‐in service pub.flow:tracePipeline. You can use 
the pub.flow:tracePipeline service in any service.
You can write this information regardless of whether you enable or disable service 
logging globally or set up customized logging for a service. For instructions on using 
these services, see the webMethods Integration Server Built‐In Services Reference and the 
webMethods Developer User’s Guide.

webMethods Logging Guide Version 7.1 46

 7. Service Log Setup and Display

Write User-Defined Messages to the IS Core Audit Log Database

To have a service write a user‐defined message to the IS Core Audit Log database, you use 
the Integration Server built‐in service pub.prt.log:logActivityMessages. You can call the 
pub.prt.log:logActivityMessages service from a service to post progress messages at certain 
points in the service’s execution (for example, to indicate whether certain segments of 
code ran successfully).
You can write these messages regardless of whether you enable or disable service logging 
globally or set up customized logging for a service. However, you can only use this service 
if you are writing logged data to a database, and you can only view the logged messages 
from Monitor.
The pub.prt.log:logActivityMessages service is stored in the WmPRT package. Its input and 
output parameters are described below.
For instructions on setting up the IS Core Audit Log database component, see the 
webMethods Installation Guide.

Input Parameters
FullMessage String Optional. Complete message to record in the IS Core Audit Log 
database. The message can be up to 1024 bytes.
BriefMessage String Optional. Shortened version of the full message. The message 
can be up to 240 bytes.
EntryType String Type of message.
Set to... To...

Message Indicate that the message is informational and no action is 
needed.
Warning Indicate that the message is a warning message. The 
business process can complete successfully even if the 
circumstance causing the warning is not addressed. 
Error Default. Indicate that the message is an error message. An 
error message will not stop the business process or put it in 
an error state. However, the business process cannot 
complete successfully until the circumstance causing the 
error is resolved. 

Output Parameters

None.

webMethods Logging Guide Version 7.1 47

 7. Service Log Setup and Display

View the Service Log

In Integration Server Administrator, go to the LogsAudit page to view the service log. 
The fields in the service log are listed below.   

Column Details
Timestamp Date and time the entry was written to the log.
User Id Integration Server user name of the client that called the service 
that generated the log entry.
Server Id Integration Server on which the service that generated the log 
entry ran and port on which the requesting client connected. The 
ID can be DNSname:port or IPaddress:port.
Service Name Service that generated the log entry.
Resubmittable Whether you can resubmit the service from Monitor. You can 
resubmit a service if it is a top‐level (as opposed to nested) service 
and the service’s input pipeline was logged.
Status Current status of the service (Started, Retried, Ended, or Failed).
Duration Length of time the service ran (in milliseconds).
Error Message If the service failed, message that describes the error that occurred.
Root Context Context information Monitor uses to connect related entries from 
Parent Context different logs.
Current Context

By default, Integration Server Administrator displays the most recent entries in the log. 
You can change various aspects of the display (see “Change the Log Displays” on 
page 50).
For information about viewing service log entries in Monitor, see the webMethods Monitor 
User’s Guide.

webMethods Logging Guide Version 7.1 48

Chapter 8. Setup for All Log Entries

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Change the Log Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Send Messages About Critical Issues and Service Failures to Email Addresses . . . . . . . . . . . . 52

Perform Additional Processing on Log Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

webMethods Logging Guide Version 7.1 49

 8. Setup for All Log Entries

Overview
This chapter explains how to:
Change various aspects of the log displays

Configure Integration Server to automatically send notifications to a specified email 
address each time a critical issue occurs or a service fails

Change the Log Displays

You can change the display of logging data pages as follows:
Specify the date and time format to use in log entries

Change various aspects of the displays temporarily

Change various aspects of the display permanently

Display logged data in different languages

Specify the Date and Time Format to Use in Log Entries

By default, log entries use the format yyyy‐mm‐dd hh:mm:ss. You can change this format to 
any other format that is supported by the Java class java.text.SimpleDateFormat.

To specify the date and time format to use in log entries:

1 In Integration Server Administrator, go to the SettingsLogging page and click Edit
Logging Settings.
2 In the Format box, type the date and time format to use. You can specify any format 
that is supported by the Java class java.text.SimpleDateFormat (for example, yyyy‐
MM‐dd HH:mm:ss z).
3 Click Save Changes.

Change the Display Temporarily

To change the display for a log page temporarily, use the Log display controls area at the top 
of the page and then click Refresh. The changes remain until you change them again, or 
until you shut down Integration Server, whichever comes first.

webMethods Logging Guide Version 7.1 50

 8. Setup for All Log Entries

If Integration Server is storing logged data in a database, most log pages offer From: and 
To: fields that let you choose the entries to display using a date range.   

Note: Using date ranges can slow system performance.

Change the Display Permanently

You can change the default for the Number of entries to display field from the default of 35, 
and you can change the refresh interval for log entries from the default of 90 seconds.  

Important! Increasing the number of entries displayed significantly can slow system 
performance. Decreasing the refresh interval significantly can slow system performance.

1 In Integration Server Administrator, go to the SettingsExtended page and click Show
and Hide Keys. Integration Server Administrator displays a list of the Integration Server 
configuration properties you can change using this method.
2 Select the check box next to the properties you want to change, as follows:   

If you want to change... Select this property...

The default for the Number of entries to display  watt.server.log.maxEntries
field
The refresh interval for log entries watt.server.log.refreshInterval

3 Click Save Changes. Integration Server Administrator displays the property in the 
Extended Settings box.
4 Click Edit Extended Settings. In the Extended Settings box, set each property to a positive 
integer.
5 Click Save Changes. Changes take effect immediately.

Display Logged Data in Different Languages

If you choose to store logged data in flat files and you want to view the data in a language 
other than English, you might have to adjust your text editor or command shell.
If you choose to store logged data in flat files, Integration Server writes the files in the 
Unicode UTF‐8 encoding. These files do not contain a Byte Order Mark (BOM, Unicode 
character U+FEFF). If the files contain non‐ASCII data, such as log entries written in non‐
U.S. English, you might have to adjust the character encoding used by your text editor or 
command shell so you can view the log entries.
On a UNIX system, you can adjust the character encoding by changing your locale setting 
(LC_ALL) to the appropriate UTF‐8 encoded locales. For example, to view Japanese 

webMethods Logging Guide Version 7.1 51

 8. Setup for All Log Entries

characters in a text editor or command shell on a Solaris system, you might change your 
locale setting to ja_JP.UTF‐8.
On a Windows system, because the files do not contain the BOM character, text editors 
such as Notepad might not detect the UTF‐8 encoding correctly. Adjust the encoding 
manually so you can view the files. To view the logs in the cmd shell, you can use the 
command chcp 65001.

Send Messages About Critical Issues and Service Failures to

Email Addresses
By default, Integration Server does not send notifications of any log entries to an email 
address. You can configure Integration Server to automatically send notifications to a 
specified email address each time:
A critical issue occurs. These issues are the critical entries written to the server log.

A service fails. These service failures are the stack track information written to the 
error log.

To send messages about critical issues and service failures to email addresses:

1 In Integration Server Administrator, go to the SettingsLogging page and click Edit
Logging Settings.
2 In the SMTP Server box, type the server name or IP address of the SMTP server to use to 
send the messages.
3 In the Internal Email box, type the email address to which to send messages about 
critical log entries. Typically, you would specify the email address for the Integration 
Server administrator.
4 In the Service Email box, type the email address to which to send messages about 
service failures. In a development environment, you might direct these messages to 
the developer. In a production environment, you might direct these messages to the 
Integration Server administrator.
5 By default, Integration Server uses character set utf‐8 for the messages. If you want to 
use a different character set, identify the character set in the Default Email Charset box.
6 Click Save Changes.
7 By default, Integration Server connects to port 25 on the specified SMTP server. Also 
by default, when sending a message, Integration Server provides its own address (the 
From Address) as Integration‐Server@localhost, where localhost is the Integration 

webMethods Logging Guide Version 7.1 52

 8. Setup for All Log Entries

Server host machine. If you want to change either of these properties, follow these 
steps:
a In Integration Server Administrator, go to the SettingsExtended page. Integration 
Server Administrator displays a list of Integration Server configuration properties 
you can change using this method.
b Click Edit Extended Settings. In the Extended Settings box, set the properties as 
follows:  

To change this...
SMTP server port watt.server.smtpServerPort=port to use

Integration Server’s  watt.server.email.from=new From Address to use

From Address

c Click Save Changes, then restart Integration Server.

Perform Additional Processing on Log Entries

If you want to perform additional processing on log entries, you can create an event 
handler. For example, you could create an event handler that sends service log entries to 
another log, such as the Event Log on a Windows system. For information, see the 
webMethods Integration Server Built‐In Services Reference and the webMethods Developer 
User’s Guide.

webMethods Logging Guide Version 7.1 53

 8. Setup for All Log Entries

webMethods Logging Guide Version 7.1 54