| # Event Publishing Settings (tlbct5505m000) Use this session to configure the Event Publishing Settings. This session can be started from the Events (tlbct5530m000) session and the Event Subscriptions (tlbct5500m000) overview session. If the porting set does not support BLOBs, the session cannot be started; therefore, it will also be invisible in the Events (tlbct5530m000) and Event Subscriptions (tlbct5500m000) session. For each event status other than ‘To be Published’, you can configure the following: Whether the events must be kept after they reach this state. Whether the event message (XML) must be kept (for Error and Published state only). How long the messages must be kept. The last two settings can only be configured if the first one is switched on. The settings apply to all companies. To store the updated settings, you can choose OK; to undo the changes and close the session, choose Cancel. When selecting OK, obsolete events are deleted if according to the new settings less history events must be kept. At runtime, deleting the history of a company is only done when at least one publisher is running for that company. The publisher Bshell will delete obsolete history data when starting; while running, it will recheck on an hourly basis. If the delete action fails, an error message is published. Changed settings are automatically picked up by the publisher Bshell at the next delete action; therefore, when changing the settings, you do not have to restart any publishers. When deleting the history, the last update time of an event is used because this is the time the event reached its final state, whether Irrelevant, Error, or Published. Therefore, if an event was triggered three hours ago and published one hour ago, it will not yet be deleted if it is configured to be deleted when older than two hours. Warning Keeping event history increases the database size and will reduce event publishing performance, especially when high volumes of messages occur or the ‘Also Keep Event Message’ is switched on. Additionally, if no publisher is running for a company, no deletion will be carried out. Note that the events are stored per company, so a table instance exists per company. Related topics Event Monitoring Events (tlbct5530m000) Fields Irrelevant Events Keep History If this check box is selected, events will be kept after they reach the Irrelevant state. Delete if older than The number of hours after which the events will be deleted. Error Events Keep History If this check box is selected, events will be kept after they reach the Error state. Also Keep Event Message If this check box is selected, the event messages (XML) will also be kept. Delete if older than The number of hours after which the events and messages will be deleted. Published Events Keep History If this check box is selected, events will be kept after they reach the Published state. Also Keep Event Message If this check box is selected, the event messages (XML) will also be kept. Delete if older than The number of hours after which the events and messages will be deleted. Too Large Events Keep History If this check box is selected, events with status "Too Large" will be kept for some time. An event gets status "Too Large" if the message size exceeds the maximum specified in the Maximum Message Size field. The event is skipped and an error message is published. You can check the business ID for a skipped event in the Events (tlbct5530m000) session. Also Keep Event Message If this check box is selected, the event messages (XML) will also be kept. Delete if older than The number of hours after which the events and messages will be deleted. Restrict Message Size If this check box is selected, you can define a maximum size for messages in the Maximum Message Size field. If the size of a message exceeds the maximum, the corresponding event gets status "Too Large". The event is skipped and an error message is published. Restrict the message size if the event publishing configuration allows, accidentally, publishing of very large event messages. In this way you can avoid publisher interruption. If this check box is cleared, LN does not check the message size. If a message is too big to be handled by the porting set or Infor Integration 6.2, one of the following happens: The publisher stops. The publisher is interrupted. The publisher reports a Java out of memory error. Maximum Message Size The maximum number of megabytes for an event message. This setting is valid for all companies and all business objects. At runtime, when an event is published from LN, the message size is compared to the maximum size. If the size exceeds the maximum, the event gets status "Too Large". As a result, the following happens: The event is not published. The publisher continues processing the next event. An error message is published. This error message does not contain the complete message, but it includes a reference to the event. The message status cannot be restored to "To be Published". If the Maximum Message Size is not filled, no check on the event message size is done. Important! The optimal Maximum Message Size depends on the involved systems and network and their configuration. Therefore Infor cannot give a "universal" default size limit. As a rule of thumb, assume messages up to 20 Mb can be handled if sufficient memory is available. When you define a maximum message size, Infor recommends to switch on the "Keep History" for too large messages. This way you can check the business IDs for skipped events in the Events (tlbct5530m000) session. To activate the changes after you change the Maximum Message Size, you must restart the publisher process. To do this, complete the following steps: Start the Event Subscriptions (tlbct5500m000) session. On the appropriate menu, click Start/Stop Publishing. The Start/Stop Publishing (tlbct5210m000) session starts. Stop the existing publishers. Restart the existing publishers. For details, refer to the session help. |