Projection¶

The following sections detail the marble capabilities for mobile apps. Anything not specified should be considered as unsupported.

Entity Set Where¶

entityset ReliableCustomers for Customer {  
   offlinefilter = [CreditRating > 5];  
}

Using the where property on an Entity Set will not work in the offline client. The client does not have direct access to the server database and cannot run PLSQL against the client database. Instead an offlinefilter expression must be used. This will allow queries on attributes and references within the entity.

Array Where¶

array ReliableCustomers(Company) to TstCustomer(Company) {  
   offlinefilter = [CreditRating > 5];  
}

Using the where property on an array will not work. This is for the same reason as the entity set where. Instead an offlinefilter expression must be used. This will allow queries on attributes within the child entity. References to the array parent are not supported in offline filters.

Sync Policies¶

Sync policy is used to define how an entity should synchronize between IFS Cloud and IFS Cloud Mobile. Depending on what type of data the entity holds, there are different sync policies that can be used. Entity data is updated on the device based on the sync policy selected.

Sync Policy: Batch¶

syncpolicy Batch {  
      syncschedule = daily at 20:00;  
}

An entity with the Batch sync policy will fetch data from IFS Cloud to IFS Cloud Mobile on a regular schedule. This means that the data in the mobile client database may not always be as up to date as the server data. Once data has synced from the server to the mobile client it will not change until the next time the sync policy defines. This is important to consider when using queries or fetch within an attribute. The data will not update automatically based on client-side updates.

Observe that you can set different sync schedules for different Batch entities.

This sync policy is used for basic data and static operational data that are not changed that frequently.

Sync Policy: Push¶

syncpolicy Push {
}

An entity with the Push sync policy will fetch data from IFS Cloud to IFS Cloud Mobile and push out the data to the mobile client as soon as possible when a change has occurred for such an entity. This means that the client database will be as up to date as it can, if you have connection. If you are offline the push data will come when you again have connection.

This sync policy is used for operational data that changes frequently and you need to have that data in the mobile client as soon as a change has occurred.

Sync Policy: ClientCache¶

syncpolicy ClientCache {  
      cacheinvalidation = after 2 hour;  
}

An entity with the ClientCache sync policy will not have any data sent to the IFS Cloud Mobile client as part of the initialization process. When a user first goes to a screen requiring data from this entity it will be downloaded and stored locally to be used again for the next request. The client cache can have expiration period which will trigger the client to refresh the data from the server. If the user accesses the data after the cache has expired and while offline, the cached data will be used until the user goes online. If data for a ClientCache entity is used within a client procedure it will be retrieved before the procedure is executed.

This sync policy is used for data that is very seldom used but you want to be able to use it when you are offline during a short time period. You also do not want this entity to be a part of the initialization process, due to performance.

Sync Policy: OnlineOnly¶

syncpolicy OnlineOnly;

An entity with the sync policy OnlineOnly will have the data retrieved from the server every time the user goes to a screen that uses that entity. If the user is offline the data will be unavailable. OnlineOnly entity data is not accessible from within client procedures.

This sync policy is used for data that is very seldom used and contains a lot of data in IFS Cloud and it is enough to only use it when you are online. You do not want this entity to be a part of the initialization process, due to performance.

Sync Policy: Incoming¶

syncpolicy Incoming;

An entity with the sync policy Incoming will not not synchronize data to the IFS Cloud Mobile, instead is used to send data from the IFS Cloud Mobile to IFS Cloud only.

This sync policy is used for data that can only be changed from the mobile client. It is very rarely used.

Sync Policy: GroupedPush¶

syncpolicy GroupedPush {
    guardcondition = "";
    ownershipquery = "";
    userfilter TstObjectAccessfilter(Contract);
    languagedependent True;
}

An entity with the sync policy GroupedPush will synchronize the same set of data to a group of users. The data is collected the first time a user within a group connects with the IFS Cloud Mobile app. When another user within the same group connects the collected data is synchronized to the user (plus any subsequent changes to the collected data).

This sync policy is used for entities with large amount of data, where the data is generally always split in specific ways to groups of users.

See more detailed description of how to implement it here.

Attributes¶

prefetch for references is not supported
compute attributes are not supported
validate is not currently supported
Stream attributes types are not supported

Binary Attributes¶

Be wary of using Binary attributes. Binary data is stored against the row in the client database table. This data is transferred to the client during the sync process. This can cause long initialize and sync times when binary attributes are used. Instead consider using the Media Library or DocMan where the data is transferred separately to the transaction sync process.

Failed Transactions¶

Failed transactions happen when the client does not apply the same validation checks as the server. Failed transactions stop any following updates from being processed by the server. Fixing failed transactions can leave the client data in an inconsistent state. Reducing failed transactions is important. See the Mobile Apps Procedures documentation for more information.

Transaction Groups¶

Entity updates and actions can be placed within a transaction group. When a failed transaction happens, further updates within the same transaction group will stop being processed. Updates within a different transaction groups will continue to process.

entity WorkOrder {  
   transactiongroup = "WorkOrder: ${WoNo}";  
}  

entity WorkOrderTimeReport {  
   transactiongroup = "WorkOrder: ${WoNo}";  
}  

action MyAction Text {  
   transactiongroup = " WorkOrder: ${WoNo}";  
   parameter WoNo Text;  
}

With the above client definition, updates to one work order will not stop updates being processed for another work order.

Functions and Actions¶

Offline actions are asynchronous, and functions are client side only. Any client definitions depending on the results of an action or function must have a client-side procedure written to provide the result and do any local side effects.

For example: Doings a status change may take a while to complete if the user has no internet connection. In this situation, the client database needs to be updated with the new status before the server completes the action. See the Mobile App Procedures documentation for more information.

Server Generated Primary Keys¶

The client generates a negative number for the server generated key columns. The client key will not match the server key until the user initializes. References must be properly defined against the entity, so the server can recognise foreign keys and link entity updates to the correct records.