When developing business events we must consider any performance impact the event might cause. As part of the send method, the contract is initialized and serialized to a JSON string. We therefore only want this code to run if required.
We can wrap the call to this using the following code:
if (BusinessEventsConfigurationReader::isBusinessEventEnabled(classStr(ConPIBOMApprovedBusinessEvent)))
{
}
This will reduce the impact if the current company does not have the event configured. The other important factor is that the business event payload must be as small as possible, and having a nested payload would usually be avoided. Should a large payload be required, consider using the business event to simply let the target know that there is something to collect. The subscriber could then use the information in the event to get the document.
The business events must have a clear purpose, such as the Bill of materials being approved. It must only send the event when we are sure that it was indeed approved and there is little or no chance that the process was rolled back due to validation failures in SCM. We should not use business events to send data through a batch routine in order to drip-feed information to a target system. We would need data entities in order to do this.