Skip to content

Split Projection

Split projection concept allows one application to refer to more than one client/projection pairs. In other words, one app file can refer to more than one client file. Since client file has a projection mapped, this will mean that the one app file can have multiple projections.

When to use this?

It is only recommended to choose split projections when there are size limitations in a singular projection SVC file such as the "PLS-00123: program too large (Diana nodes)" error. As the split projection concept complicates the app code and structure, it should not be used for simple Aurena Native apps.


  • As mentioned above, only use this if there are constraints with SVC size.
  • It is good to split the app by functionality-based client/projection pairs.
  • There will be no possibility of cross projection references. However, it is allowed to navigate to a page in another client file by specifying the client name as a prefix.


Below are the changes you need to do to use split projection in your application development

Changes in App model

Multiple client models can be added to an app file. See example below where two client models are referred (FndMotOffline1 and FndMotOffline2).

appname FndMotOfflineMulti;
component FNDMOT;
layer Core;
description "Aurena Native Internal Multi Client Models App";
version 1.0.0;
clientmodel FndMotOffline1;
clientmodel FndMotOffline2;

Overriding entities

Entities can be overridden and new columns can be added to them in projections (standard Marble usage). Now that more than one projection can be referred from an app, multiple overridden versions of an entity could exist.


  • Entity A (3 columns by default) → overridden in projection A (new column "c1" added)
  • Entity A (3 columns by default) → overridden in projection B (new column "c2" added).
  • App "TestApp" refers to these two client models that refer to projections A and B.

The mobile client will now create a local table for the entity A with 5 columns. This will include the 3 default columns along with columns "c1" and "c2". Before any transaction is performed in this entity, client will check for the current projection in use and pick the correct set of columns.

The important thing to note is that even though there are multiple versions of an entity (from various projections), there will be only one database table on the mobile client for it.

Limitation - Same column name should not be used when overriding an entity in different projections. This will cause conflicts when split projection concept is used in an application as it's not possible to know which of the column definitions should be used when creating the local table in the mobile client.

Excluding attributes in entity override

If the same attributes are excluded in the entity on all the projections, that attribute will be excluded from the client. Otherwise exclude attributes and use attributes usages in a projection may not work as expected, if there are other projections that use those attributes. For example, if you exclude attribute c1 for a given entity from projection A, but projection B doesn't, it will still be synced to the mobile client.

New syntax introduced in the App model

Due to the need to share some characteristics of an entity, some syntax which was previously defined in the projection had to be moved to the app model. For example, the sync policy of an entity could not be allowed to be defined in the projection anymore, as there could be different projections that override the same entity. In any case where these are defined in the app model and the projection, the app model takes priority. Having these only defined in the projection for a split projection app may cause unexpected behavior.

Properties for entities now should be defined in the app model. This will be common for all the client/projection pairs connected to the app. This can be done under the syncentities section.

Below properties for entities and queries can be defined in the app file now,


syncentities {
   entity FndMotCompany {
      syncpolicy Batch {
         syncschedule = daily at 20:00;

   entity FndMotOffWorkOrder {
      transactiongroup = "WorkOrder: ${WoNo}";
      syncpolicy Push {
         syncschedule = daily at 20:00;
         guardcondition =
            "FUNCTION Push_Guard RETURN BOOLEAN IS
                 RETURN TRUE;
         ownershipquery = "SELECT user_id FROM mobile_user";

   query AcceptedWorkOrderCompanies {
      syncpolicy None;
      offlinequery = from AcceptedWorkOrders awo
      join FndMotOffWorkOrder wo on wo.WoNo = awo.WoNo
      left join FndMotCompany co on co.Company = wo.Company
      select awo.WoNo, wo.Company, co.Name;

   entity MobileIntegration {
      offlinewhere = "FEATURE_TYPE_DB IN ('WEB', 'APK') AND ACTIVE_DB = 'TRUE'";
      syncpolicy Batch {
         syncschedule = daily at 00:00;

   entity EquipmentObjectParty {
      syncpolicy GroupedPush {
         userfilter EquipObjAccessFilter(Contract);
         languagedependent True;

      changedetection {
         trigger on Equipment_Object_Party_Tab {
            attributes {
               attribute Contract;
               attribute MchCode;
               attribute Identity;
               attribute PartyType;
               attribute DeliveryAddress;
            objkey Objkey;

Other changes in the App model

Prefixing the client or projection name (whichever is applicable) is required when referring to an entity/query/entity set/action/function in the below places. An example for an entity would be FndMotOffline1.FndMotOffWorkOrder.

  • Security groups
  • Contact widget source
  • Address field source
  • Push notifications
  • Status indicator

Projection changes

  • Remove the entity/query properties that were added to the app model from all the projections. They are no longer necessary here.
  • Review usages of use attributes and exclude attributes to eliminate any ambiguity as it may contradict how the app actually works.