Introduction
Policies control if an event will be logged to database and they also control if an event will be passed as a message to an adapter, for instance the built in error-notification email adapter. Adapters and Integrations can be configured to have their own policies. This is optional and causes all events that occur in the context of the particular adapter or integration to be filtered by its chosen policy. When there is no such policy selected for an adapter or integration, the system policy will be used. A policy can have several policy item entries that narrow down which events to filter.
The picture above shows the default system policy for events in the Integration server. Notice the use of wild-cards to catch categories of events.
We're now editing a policy in the Event Policy Repository. So far we've not chosen any events to handle.
If we press the + button, then a policy item is added to policy. Pressing X removes a selected policy item, while the up and down arrows rearranges the order of the items.
The five columns in the table are:
Type
This is the server friendly name of the event. For example, the archive process creates events such as ibzArchive:Started. You can use * as a wildcard. For example, you can match all archive events by entering ibzArchive:*. The drop down list is automatically filled with events created by adapters, integrations and scheduled tasks that use this policy.
Adapter
This is a drop down list of all available adapters. If an event matches this policy item, this is the adapter the event will be sent to. In the example picture above, note that *, *:info* and *:warning* is set to not forwarding the event message to an adapter.
Notes
You can type your own information here.
Group
Events are grouped together. The server first tries matching all policy items in group one. If it gets a match, it then stops. If there were no matches, then group 2 is tested, and so on. This way, an event could
On
You can disable a policy item by removing the On check / tick. A policy item that is not On is treated as though it does not exist by the server.
Introduction
A transaction is started when data enters an adapter. Normally an input adapter. The data is converted and sent to an output adapter. Integration Server will keep track of this progress by keeping a transaction record, this progress can be seen in WISM where the state and stage of transactions are displayed. This information is crucial to the execution of the whole transaction, its the context of the transaction.
Events represent at different type of information. Events carry information about what happens inside Integration Server, both relating directly to transactions and more general messages about what the server is doing.
Log messages written by the server
Previous versions of the Integration Server wrote messages into log files like the example below.
2011-04-08 14:52:13 MSG. DISP 0 INFO Message processes dispatcher uses 1 worker threads.
2011-04-08 14:53:24 ADAPTER 14002 WARNING Tried to start a none existing Adapter
2011-04-08 14:58:09 ADAPTER 14002 WARNING Tried to start a none existing Adapter
2011-06-14 14:40:55 UNKNOWN 0 FATAL Initialize process manager failed.
In the current version, these kind of messages are inserted into the server's database. Notice the texts INFO, WARNING and FATAL. These texts specify that something has been logged from the server after some EVENT has occurred. It may be just an information message (INFO), a message with some text which warns about something (WARNING), an error message (ERROR) or a message describing a fatal error (FATAL).
The events triggered in Integration Server are categorized as Info, Warning, Error or Fatal. This reflects what is the considered severity of the information that is given by Integration Server. The categories exist as a naming convention, and are there to make it easier to create policies that filter most information with few settings. But one can easily edit a policy to treat events of type Warning in the same way as we treat any other events. For more information about setting up policies and filtering of events (info, warning, error and fatal) see 4.8.2 Policies.
What is regarded as an event by the server
Logging from within user mappings and EDI-C code. If you make a call to the EDI-C function loginfo, the server treats this as if an event of the type INFO has occurred. If you call the function log, the server treats this as if an event of the type ERROR has occurred.
Other types of events are triggered if adapters and other parts of the server starts and stops. There exist a lot of other situations when the server triggers events.
INFO
This event can be triggered by the server and a call to the loginfo function
WARNING
A typical warning event is triggered when an adapter tries to connect to a remote computer and fails doing so. This is probably not an error in the server. This event may be triggered by a communication error caused by wrong settings.
ERROR
A typical error event is triggered when a FTP adapter has tried several times to connect to a remote server and failed doing so. Another instance when this event is triggered is if an EDI-C has called the function log.
FATAL
These kind of events are triggered when something has happened that seriously reduces the functionality of the server. These kind of errors should be taking care of as soon as possible.
Logging from within user mappings and EDI-C code. If you make a call to the EDI-C function loginfo, the server treats this as if an event of the type INFO has occurred. If you call the function log, the server treats this as if an event of the type ERROR has occurred.
Other types of events are triggered if adapters and other parts of the server starts and stops. There exist a lot of other situations when the server triggers events.
Overview
Below is a picture that shows the flow of log messages in the Integration Server. Note that both adapters and integrations can trigger events. How the event-messages should be handled for each adapter/conversion can be set - more about how this is done see the chapter that describes how events should be handled (4.8.2 Policies).
Events originate in more places then suggested by the picture. Including the contexts outside of adapters and integrations. And most these context can generate all categories of events.
In the picture above we can see how there are two levels of policy (Optional Adapter/Integration Policy and System Policy). One policy can be set to be the system policy.
Event content
An event have these data, Event type and Text. It also has additional data about the context under which it was created such as Time, Transaction ID and Definition ID.
Event type
Short text of at most 128 characters, this is what is filtered by policies.
Example: global:servercore:server:info
The naming convention used by Integration Server works by separating levels of context with the colon character (:), and eventually ending with a category. At times a specific identifier is also appended to further specify the event.
Text
A text describing the event in a human readable format. This text can be max. 1024 characters.
Example: Server started
Time
Timestamp when the event occurred.
Transaction ID
ID of the transaction where the event originated. If the event originates in the context of a transaction, the transaction ID will be here.
Definition ID
ID of the definition where the event originated. If the event originates in the context of an adapter or integration, that definitions ID will be here.
Note Adapter IDs begin at 14000 and integration IDs begin at 15000.
Policy
To control events there is something called Policies for events. Read more about how to set up policies in 4.8.2 Policies.
0 Comments