Well-defined events can make it easy for support personnel to investigate call processing issues, and well-used events can minimize the amount of data that your application sends, therefore saving the network bandwidth and the storage space that your application uses.
Follow these guidelines when you define or use events:
-
Assign appropriate event levels.
For details, see Event level.
-
Minimize event data for protocol events.
If a resource adaptor already sends a SAS event containing a protocol stack message, don’t send the same stack message in SAS events at the application layer. Doing that wastes the bandwidth and storage space and may also clutter the SAS trace with redundant information that reduces the clarity of the trace.
-
Be aware of event ordering.
Send SAS events inside a service before calling down to a resource adaptor to send a protocol message. This way the event you create will precede the resource adaptor’s SAS events and provide context and explanation for them.
-
Consider the entire narrative of the SAS trace.
The goal in sending SAS events is to record a concise, linear narrative of what happened and why, both in normal and abnormal flows. By ensuring a coherent SAS narrative as a whole on the SAS server, we can afford the SAS user a greater understanding of what went wrong in instances where the call flow is unexpected.
