Tutorials

  1. Home
  2. Docs
  3. Tutorials
  4. 63.What is the mode By-pass the message layer and when to use it?

63.What is the mode By-pass the message layer and when to use it?

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

Note
– Future Apex => process as Future job and we can see it call Apex class IServices and Apex method reprocessAsynch
– 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

 

CaseDon’t Persist

Message

By Passing

Message checked

Interface modeDescription
Use By passing message flag only
1YesSynchronous

(None, Immediately)

No message created. We can only see

record of sobject created on salesforce

2YesBatch ApexNo message created. We can only see

record of sobject created on salesforce

3YesQueueable ApexNo message created. We can only see

record of sobject created on salesforce

4YesFuture ApexNo message created. And no record create.
Use both flag: By passing message flag and Don’t persist message
5YesYesSynchronous

(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
7YesYesQueueable ApexNo message created. We can only see

record of sobject created on salesforce

8YesYesFuture ApexNo 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
13Synchronous (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.

Was this article helpful to you? Yes No

How can we help?