The CommerceCloud module was introduced to support SaaS properly and to decouple the changes required for it in the core modules:
The module includes all required customizations that allow LS eCommerce – Magento to run seamlessly on SaaS.
Since on SaaS the web sync module has its own status for replication jobs, LS Commerce will not use LastKey. Instead, the Web Sync module uses an AppID for maintaining status. For that purpose, a unique AppID is created in the CommerceCloud module and passed per replication job per store.
For example, an AppID is created for ReplEcommAttribute, if it is running for the first time for Store S0013 and then the same AppID is used only for ReplEcommAttribute for subsequent calls.
[2021-09-15 13:42:40] OmniLoggerHandler.DEBUG: ==== REQUEST ==== 09-15-2021 13:42:06.606027 ==== ReplEcommAttribute ====
[2021-09-15 13:42:40] OmniLoggerHandler.DEBUG:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://lsretail.com/LSOmniService/Loy/2017" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns2="http://lsretail.com/LSOmniService/EComm/2017/Service">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<ns2:ReplEcommAttribute>
<ns2:replRequest>
<ns1:AppId>fc5f8bf0-a0eb-4b66-afc2-6329564d70fa</ns1:AppId>
<ns1:BatchSize>2000</ns1:BatchSize>
<ns1:FullReplication>false</ns1:FullReplication>
<ns1:LastKey>25</ns1:LastKey>
<ns1:MaxKey xsi:nil="true"/>
<ns1:StoreId>S0013</ns1:StoreId>
<ns1:TerminalId xsi:nil="true"/>
</ns2:replRequest>
</ns2:ReplEcommAttribute>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
[2021-09-15 13:42:40] OmniLoggerHandler.DEBUG: ==== RESPONSE ==== 09-15-2021 13:42:40.411402 ==== ReplEcommAttribute ====
[2021-09-15 13:42:40] OmniLoggerHandler.DEBUG: ==== Time Elapsed ==== 0 minute(s) 33.805375 second(s) ==== ReplEcommAttribute ====
[2021-09-15 13:42:40] OmniLoggerHandler.DEBUG:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<ReplEcommAttributeResponse xmlns="http://lsretail.com/LSOmniService/EComm/2017/Service">
<ReplEcommAttributeResult xmlns:a="http://lsretail.com/LSOmniService/Loy/2017" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<a:Attributes>
<a:ReplAttribute>
<a:Code>DIET</a:Code>
<a:DefaultValue/>
<a:Description>Dietary Preferences</a:Description>
<a:IsDeleted>false</a:IsDeleted>
<a:ValueType>5</a:ValueType>
</a:ReplAttribute>
</a:Attributes>
<a:LastKey>27</a:LastKey>
<a:MaxKey i:nil="true"/>
<a:RecordsRemaining>0</a:RecordsRemaining>
</ReplEcommAttributeResult>
</ReplEcommAttributeResponse>
</s:Body>
</s:Envelope>
As mentioned in the Replication Grids topic, there is a link available in cron listing to reset each individual cron. This link basically removes the status counters including AppID for each cron so that it uses a new AppID whenever it runs again.
Note: There are also other ways available to reset the status from LS Commerce and LS Central as described in Replication for LS Central in SaaS.
Current limitations and their workaround
Since LS Commerce has no access to LS Central database on SaaS, it uses web services to retrieve data from LS Central. It is also noticed that you might experience timeouts while using a higher batch size or if the number of requests per minute exceeds the allowed maximum.
Therefore, we recommend to use a smaller number for batch size while replicating in order to keep such situations at a minimum.
For more information about Microsoft Business Central SaaS operational limits, click here.