xBus

standard.conf
Basic Definitions

The description of the standard.conf parameters has been improved compared to previous releases and is a good source to understand its entries. But still you will find the real truth in the provided standard.conf file under XBUS_HOME/etc and in the configuration files for the repeatable tests under XBUS_HOME/test.


This section comprises some basic configuration of the xBus affecting things like tracelevels or timeouts.

Note that all entries of the Base section are pre-configured with good default values and usually must not be changed. The tables below describe all basic fields and their possible values.

 
 Trace

global    required

chapter section key example
Base Trace Level Base_Trace_Level=3

Trace writes program-internal informations to the console or a file. Using this parameter, you can control how much information will be traced.

Currently levels 0 to 4 are supported.

  • 4 = DEBUG: Intended only for the development phase or error diagnostic, really lots of information will be traced.
  • 3 = INFO: Information which can be helpful during the test phase, e.g. begin and exit points of some important methods.
  • 2 = WARN: Warnings in the presence of irregularities.
  • 1 = ERROR: Only error messages will be written.
  • 0 = ALWAYS: There are some trace entries which will be written always.
For productive operation, trace level 2 should be selected, to have only exceptional situations in the trace.


global    required

chapter section key example
Base Trace Tracer Base_Trace_Tracer=FileTrace

This entry allows to choose the target where the trace is written to:

  • ConsoleTrace - trace will be written to the console
  • FileTrace - trace will be written into a file (the following entry with the filename is required)


global    required

chapter section key example
Base Trace MaxLength Base_Trace_MaxLength=999999

This parameter sets the maximum length of a trace entry. Lines longer than the maximum value will be truncated.


global    optional

chapter section key example
Base Trace Filename Base_Trace_Filename=trace.log

This entry specifies the name of the file, where you want your traces to be written. It is required only for FileTrace.

Only the name of the file is needed, not the absolute path. The file is created relative to XBUS_HOME/log/.


global    optional

chapter section key example
Base Trace MaxFileSize Base_Trace_MaxFileSize=150000

This parameter sets the maximum length of a trace file. It is only necessary for the use of the trace file renamer. Whenever the trace file renamer is started, it will look for the trace file size. If its is more the specified value in bytes, the trace file is renamed by adding a timestamp. The next tracing will create a new trace file with the old name.

 
 Journal

The following entries decribe the way of journaling. Whether a journal entry is written or not is ruled by system-specific configuration parameter.


global    required

chapter section key example
Base Journal Implementation Base_Journal_Implementation=DBJournal

This entry allows to choose the target where the journal is written to:

  • DBJournal - The journal will be written into a database (some setup has to be done before).
  • FileJournal - The journal will be written into a file named XBUS_HOME/log/journal_yyyymmdd.log

 

global    required

chapter section key example
Base Journal MessageLength Base_Journal_MessageLength=1024

This parameter defines the maximum number of bytes used for the request-message and the response-message. Messages longer than this maximum value will be truncated.

 
 Error notification

global    optional

chapter section key example
Base NotifyError System1..n Base_NotifyError_System1=ErrorMail
Base_NotifyError_System2=ErrorLogFile

This parameter defines senders for error notification. The error notification happens, when a message cannot be processed and all retries have failed.

Typically a SMTPSender is specified to notify an administrator via email. But as a matter of principle all other senders could be used as well. Currently there is a technical limitation: The senders must not use transaction handling (cf. the respective tables in the chapter Technical Layer.

If no sender is specified, there is no error notification mechanism.

Note:

  • Although this parameter is optional, it should not be ignored, because it is usually safer to be informed in time in case of an error.
  • Each listed system must be defined with all necessary parameters from the System chapter.


global    optional

chapter section key example
Base NotifyError MessageLength Base_NotifyError_MessageLength=100

This parameter sets the maximum length of the message to send in the case of an error. Entries longer than the maximum value will be truncated.

The parameter is only necessary if at least one system for notifying errors was defined above.

 
 Error Handling

global    required

chapter section key example
Base Receiver WaitAfterError Base_Receiver_WaitAfterError=5

This parameter will be used by all background receivers (except HTTPxxxReceiver). It specifies the time interval in seconds, how long the background receiver will wait before trying to process a message again in case of an error.

 

global    required

chapter section key example
Base FileReceiverThread
MQReceiverThread
POP3ReceiverThread
HTTPReceiver
StopAfterErrors Base_HTTPReceiver_StopAfterError=-1

Background receivers can be stopped after a specified amount of errors without a successful processing between them. -1 means this kind of background receiver will not be stopped automatically at all.

 
 Background Receivers

For more information about background services see here.


global    required

chapter section key example
Base FileReceiverThread
MQReceiverThread
POP3ReceiverThread
Timeout Base_FileReceiverThread_Timeout=1

These background receivers use a polling mechanism to check wether a message is available. This is the global definition of the delay between the attempts in seconds.

Note This value may be overruled by a system-specific timeout.


global    optional

chapter section key example
Base ReceiverService PreProcessor Base_ReceiverService_PreProcessor=FolderPreparator
Base ReceiverService PreProcessor1..n Base_ReceiverService_PreProcessor1=FolderPreparatorIn
Base_ReceiverService_PreProcessor2=FolderPreparatorOut

The configured pre-processor(s) is(are) executed directly when the receiver service is started.
Using the PreProcessor notation without index number allows declaring just one pre-processor. This possibility is still in after the extension to multiple pre-processors for compatibility reasons.

 
 Address Implementation

global    optional

chapter section key example
Base System AddressImplementation Base_System_AddressImplementation=net.sf.xbus.Dealer

As explained on the Concepts page, most of the systems need some kind of address, where to read or write the data. Use this parameter to specify the name of a class, that enables an easy access to specific address information of your installation.

 Variables

global    optional

chapter section key example
Base Variable variable name Base_Variable_BufferDir=$XBUS_HOME$/buffer

Variables allow defining repeated strings centrally, e.g. often used directory paths. As shown in the example the XBUS_HOME parameter my be used in variable values because it will be replaced prior to replace the variable within other terms.

 Deleted Message Store

global    optional

chapter section key example
Base DeletedMessageStore Enabled Base_DeletedMessageStore_Enabled=true

Setting this entry to true lets all deleted messages be written into the Deleted Message Store. If this entry doesn't exist or is set to false, the decision about using the Deleted Message Store can be made per system.


global    required

chapter section key example
Base DeletedMessageStore Directory Base_DeletedMessageStore_Directory=$XBUS_HOME$/log/DeletedMessages

Defines the directory, where the files with the deleted messages shall be written to.

 XML

global    optional

chapter section key example
Base XML Encoding Base_XML_Encoding=UTF-8

This entry stores the default encoding to be used for parsing and serializing all kinds of XML messages. If not set, the default UTF-8 is used.


global    optional

chapter section key example
Base XML TransformerFactory Base_XML_TransformerFactory=com.example.xml.CustomTransformerFactory

Used to provide a custom XML transformer factor. It sets the class name of the factory including the package name. The jar-file containing the TransformerFactory must be placed in XBUS_HOME/lib/runtime.