Learning Objective:
After completing this unit, you’ll be able to:
- Describe What is the mode By-pass the message layer.
- Comfortably use By-pass the message layer mode.
Introduction #
We have the flag: ‘Don’t persist message’ to delete the message again after the processing. When the flag ‘by-pass Message Layer’ is checked then even failed message is not created. This will help to spee up processing.
What is By-pass the message layer mode? #
The new flag is ‘By-passing message layer’ is be used for all e.g. inbound and outbound message processing and with all mode. It doesn’t depend on the mode anymore if it is synchronous or asynchronous. If the user uses this flag then the message processing takes place only in the memory and not database operation is done with the massage table. The processing speed is very high and also there is no pending database record at Salesforce backend side anymore. This is a perfect mode for having speed in the processing.
Why we add By-pass the message layer mode? #
Message Layer redesign to reduce data storage consumption. We have the flag: ‘Don’t persist message’ to delete the message again after the processing. The problem is that we have created the message in the first step and after processing it we delete it again from the database. Thus we needed two database operation. This has a bad impact of the database record which still kept in the Salesforce database center even we have hard-deleted them from apex layer.
When the flag ‘by-pass Message Layer’ is checked then even failed message is not created. Also It will not create a message in the database. It will dominate the interface mode.
Advantage #
Some customer criticizes our solution that we use data storage from their Org. Unlike the API (soap, rest) which is just the api call to CRUD the sObject the only storage they need is the storage to create the sObject. There is no other data storage which is needed. With this flag, we want to provide such an option as well and thus we can save that we behave the same way like an API. But we have more functionality e.g. our step with workflow and mapping which add more functionality to the message processing. Our processing can do some more logic e.g. workflow and mapping before it does the posting e.g. CRUD like the normal API. This we have workflow+mapping+CRUD. The api has the only CRUD. This is our advantage against the standard API but doesn’t use the data storage.
But we have the flexibility to by-pass or still use the message layer. When we use the message layer then we can still have monitoring and reprocessing feature. But when due to data storage shortage customer cannot afford to use the data storage then we have to by-pass and renounce the benefits with monitor + reprocessing. But we still have workflow + mapping + alerting.
Dis-Advantage #
The disadvantage is that we lose the message monitoring because there are not message anymore created in our massage table.
How to use By-pass the message layer mode? #
Step 1: Create Integration.
Step 2: Create Inbound Interface. (Source Name: Account, Status: Deployed, Operation Type: Upsert)
Step 3: check By-pass the message layer check box.
- Go to Information section.
- scroll down the page to “By-pass the message layer” check box.
Step 4: Changing inbound process mode:
Go to interface detail => Inbound Posting Behavior
- Synchronous: None (is default value:Syn.), Immediately
- Asynchronous: Future Apex, Queueable Apex, Batch Apex
– Queueable Apex => process as Queueable job and we can see it call Apex class InboundPostingBehaviorQueue
– Batch Apex => process as Batch Apex job and we can see it call Apex class IServicesBatchV2
Case | Don’t Persist Message |
By Passing Message checked |
Interface mode | Description |
Use By passing message flag only | ||||
1 | Yes | Synchronous (None, Immediately) |
No message created. We can only see record of sobject created on salesforce |
|
2 | Yes | Batch Apex | No message created. We can only see record of sobject created on salesforce |
|
3 | Yes | Queueable Apex | No message created. We can only see record of sobject created on salesforce |
|
4 | Yes | Future Apex | No message created. And no record create. | |
Use both flag: By passing message flag and Don’t persist message | ||||
5 | Yes | Yes | Synchronous (None, Immediately) |
No message created. We can only see record of sobject created on salesforce |
6 | Yes |
Yes |
Batch Apex |
No message created. We can only see record of sobject created on salesforce |
7 | Yes | Yes | Queueable Apex | No message created. We can only see record of sobject created on salesforce |
8 | Yes | Yes | Future Apex | No message created. And no record create. |
Use Don’t persist message flag only | ||||
9 | Yes |
Synchronous (None, Immediately) | No message created. We can only see failed message or pending message on monitoring |
|
10 | Yes |
Batch Apex |
Message create then it delete from database if it complete and We can see failed message or pending message on monitoring. |
|
11 | Yes |
Queueable Apex |
Message create then it delete from database if it complete and We can see failed message or pending message on monitoring. |
|
12 | Yes |
Future Apex |
Message create then it delete from database if it complete and We can see failed message or pending message on monitoring. |
|
No check any flag | ||||
13 | Synchronous (None, Immediately) | Message create normally: complete, failed, pending. We can see these message on monitoring. |
||
14 | Batch Apex |
Message create normally: complete, failed, pending. We can see these message on monitoring. |
||
15 | Queueable Apex |
Message create normally: complete, failed, pending. We can see these message on monitoring. |
16 | Future Apex |
Message create normally: complete, failed, pending. We can see these message on monitoring. |