The new function (streaming API) is used with the outbound interface. We are supporting the following Salesforce event type e.g.
- Streaming API with pushTopic
- Generic Event -> This is not supported because it just a plain text that we can transfer to the external application
- CDC Event
- Platform Event
Streaming API with PushTopic
In this case, we have to set the flag ‘Streaming, CDC, and Platform Event’ to indicate that the interface operates as an event interface. To distinguish this type from the CDC and Platform Event we have to check the field ‘Source/Target’ that contains the sObject. If it is a sObject and the flag is checked then we know that this interface operates in the mode ‘Streaming API with ‘PushTopic’. In the message type, we define the external message type structure for example the database structure when we want to send data triggered by the event to the database. We can do the mapping from the sObject (source) to the message type (target) side. This mapping is needed to build the transformation logic on the Agent to the external message type structure for example to send to the database.
We have a table in the Agent where we store the interface-id, status, and some other event-related data. This table is created or updated when the user clicks on the button ‘Subscribe’ of the interface on the Agent Control Board. This table is used for internal logic processing inside the agent for the event-driven interface processing. Based on this table we can find the interface and related mapping when an event occurred and the cometD client in the Agent catch this event. With the cometD capability in the Agent, it can subscribe to the event from Salesforce.
When the event gets received we need to find the interface and its related mapping. Knowing this we can transform the data that we received as an event to the external message type structure and send it to the database. A mapping is mandatory in order to do this transformation from the event data to the external data structure based on the message type. In the Agent we have to check and if there is no mapping we have to raise an error in the log.
When we receive the event data we create a message of type ‘Event Message’ in our message table. Doing this way we can provide a kind of event monitoring in Salesforce pushing out to the Agent. We can also do a reprocessing if needed. In this case, we will republish the event again based on the event data in the message. Note that this function is only available for the event type ‘Platform Event’ and not for ‘PushTopic’ and ‘CDC’ event.
CDC Event
In this case, we don’t have a SQL to select which data is needed to be sent. All changed data will be automatically sent as events to the Agent. For the CDC event, we just need to set the flag, select the xxxChangeEvent object in the interface on the field ‘Source/Target’ field, for example, AccountChangeEvent, or LeadChangeEvent, OpportunityChangeEvent, etc.. In the message type again we put the external message type. Then we can do the mapping from the sObject field to the external message type. The flow is the same that when the user change, insert, delete, or undelete data an event is created and the Agent will receive all the field that has been changed. In Agent, we are checking the mapping and transform the event data to the external structure based on the mapping. This means that when there is no mapping we need to raise an error and write into the log.
We don’t need to select the operation ‘Insert’, ‘Update’, ‘Delete’ and ‘Undelete’. This operation is pre-selected by default setting when the CDC event is used. Therefore there is no need to configure this operation as we do for the CDC Event trigger with apex. Like case (1) we also create a message for the monitoring. Also, this kind of message cannot be reprocessed by the reprocessing job.
Platform Event
Here we have to create an event object first. Those objects will have the suffix __e to indicate that it is an event object. This object needs to be put into the field ‘Source/Target’ field on the interface. Again like cases (1) and (2) we have to put the external message type into the field message type to represent the external application structure. Here we also create an event message for monitoring and this message we can reprocess. Reprocessing means that we use the apex code to publish the event again from the event message data. We have to delete the previous red message when we publish again the event because we want to keep one event-message for monitoring only. If it failed again we will see a new red event-message.
Streaming API subscription button is added on interface tab of new agent control board. #