Evaluating Service Layer Direct

SAP Commerce Cloud currently supports two ways for the service layer to interact with the persistence layer.

• Jalo is our legacy mechanism and is still the default to support backward compatibility.
• Service Layer Direct (SLD) is more efficient and uses fewer resources. It can be used on an as-needed basis in your Java code or when invoking ImpEx.

Find out more about SLD (and its comparison with Jalo) in the following representation.

The previous image provides a brief comparison of the traditional Jalo persistence method and the SLD framework pertaining to write operations in SAP Commerce Cloud. The Jalo-based approach involves iterating over numerous heavy persistence objects supported by the cache during write operations. In contrast, the SLD framework collects a set of changes from the models directly and atomically persists them, using JDBC batch writing.

Moving on to read operations in the comparison between Jalo and SLD, as illustrated in the previous image, there's a significant difference, performance-wise. SLD caches fewer elements per item read than Jalo, thus providing it with a notable performance advantage.

Considering the benefits of using SLD over Jalo, let's explore further when we can enable SLD for practical use.

There are various approaches for different use cases to enable SLD.

Globally, you can set the property persistence.legacy.mode to false. This setting enables writing and reading through SLD persistence, in general.

However, this is not recommended because there are some predefined SAP Commerce Cloud item types, which can only be persisted through the Jalo persistence layer.

Therefore, the property is set to true by default. This enables the Jalo persistence layer to remain as the primary method for persistence.

However, just for the current session context, you can use the API.

1234567

PersistenceUtils.doWithSLDPersistence() -> {
final TitleModel title = modelService.create(TitleModel.class);
title.setCode("foo");
modelService.save(title);
return title;
});

Furthermore, in distributed ImpEx, it’s also possible to enable SLD persistence specifically by configuring the import config object on the API level.

importConfig.setSldForData(true);

Or you can also enable or disable SLD in the ImpEx header, for example, with the sld.enabled=true directly as a modifier attached to the type within the header.

1234

INSERT_UPDATE Title[sld.enabled=true];code[unique=true]
;foo_sld_forced_by_header
;bar_sld_forced_by_header