ORDA – Optimize performance with full control over REST requests

Automatically translated from English

With a previous version, you discovered how ORDA REST requests had been automatically optimized to increase performance when working with a remote datastore and client/server configurations.

You learned that you can use contexts to take advantage of the automatic ORDA REST requests optimization.

That was a significant step, but now we offer to have complete control over the behavior of your REST requests. Since performance is a strategic concern, you must be eager to discover this new feature!

And that’s not all; new tools are now available to help you understand and debug your issues.

Keep reading for a complete presentation.

HDI: How do I get started with REST requests control?

Do you remember what context is?

Before starting, here is a quick summary:

  • when working with an entity selection, after a learning phase, 4D automatically triggers optimized requests (asking the server pages of entities with only the appropriate attributes)
  • you can use a context to make that optimization persist and reuse it when working with other entity selections (or entities)


Have you heard about the orda cache?

When requesting data to the server with ORDA, it is put in the ORDA cache on the client machine.

The ORDA cache is organized by dataclass. The loaded entities are stored in the ORDA cache as objects containing the contents of the requested attributes.


For more details about contexts and ORDA cache, watch the Summit 2020 session.

The new step: take complete control of the contexts

As you understood, the attributes of a context are defined by 4D’s learning phase. Thanks to the datastore, the great step forward is that you can now decide what attributes you want to include in a given context with the .setRemoteContextInfo()function.


In this example, we put the firstname and lastname attributes of the Persons dataclass in the context contextA.

Thus, when calling the all() function, the first Persons entity is not fully loaded for the learning phase. Requests sent to the server are already fully optimized.

var $ds : 4D.DataStoreImplementation
var $contextA : Object
var $persons : cs.PersonsSelection
var $p : cs.PersonsEntity
var $text : Text

$ds:=Open datastore(New object("hostname"; "school.acme.com"); "schools")

$ds.setRemoteContextInfo("contextA"; "Persons"; New collection("firstname"; "lastname"))
$contextA:=New object("context"; "contextA")
For each ($p; $persons)
 $text:=$p.firstname+" "+$p.lastname
End for each

about list boxes

Note that if the $persons entity selection is used in a list box, you can specify the attributes you want in the page mode context.

In the example below, the list box context contains the firstname and lastname attributes of the Persons dataclass.

When selecting an entity, it is immediately loaded with the attributes of the current item context (firstname, lastname, children, gender).

There is no more learning phase requiring the first entity to be fully loaded.

var $contextPersons : Object
var $listAttributes; $pageAttributes : Collection

$contextPersons:=New object("context"; "persons")
$listAttributes:=New collection("firstname"; "lastname")

Form.ds.setRemoteContextInfo("persons"; Form.ds.Persons; $listAttributes) //Form.ds is a remote datastore

$pageAttributes:=New collection("firstname"; "lastname"; "children"; "gender")
Form.ds.setRemoteContextInfo("persons"; Form.ds.Persons; $pageAttributes; "currentItem")

Form.persons:=Form.ds.Persons.all($contextPersons) //Form.persons is displayed in a list box

handle page length for entity selections

Be aware you can set a page length for entity selections requested by the server. The good news is that this also applies to attributes of kind-related entities.

The Address entities are requested to the server by pages of 100 entities with the city attribute in the example below.

For each Address entity, the related entities persons (entity selection) are requested by pages of 50 entities with the attributes firstname and lastname.

var $ds : 4D.DataStoreImplementation
var $contextA : Object
var $addresses : cs.AddressSelection
var $a : cs.AddressEntity
var $p : cs.PersonsEntity
var $text : Text

$ds:=Open datastore(New object("hostname"; "school.acme.com"); "schools")

$ds.setRemoteContextInfo("contextA"; $ds.Address; "city, persons:50, persons.lastname, persons.firstname"; "main"; 100)

$contextA:=New object("context"; "contextA")

For each ($a; $addresses)
$text:=$text+"/ "+$a.city
 For each ($p; $a.persons)
  $text:=$text+" - "+$p.firstname+$p.lastname
 End for each
End for each

the ORDA cache

Other useful tools are provided to handle the ORDA cache timeout and maximum size and means to inspect the contents of the ORDA cache.

More information is available on the documentation website.

For example, you can modify the ORDA cache timeout to adapt the frequency of your requests. This is useful when you know if your data is likely to change often or not.


In the example below, the Cities dataclass contains zipcodes and cities which are not likely to change very often, so the timeout is extended. 

var $ds : 4D.DataStoreImplementation
$ds:=Open datastore(New object("hostname"; "school.acme.com"); "schools")
// The entities will expire after 3 hours
// There are 350 entities maximum in the cache of the Cities dataclass
$ds.Cities.setRemoteCacheSettings(New object("timeout"; 10800; "maxEntries"; 350))

To save memory, you can also update the maximum number of entities present in the cache for each dataclass. 

inspect and reset the contexts

To help you dive into this fascinating subject, visit the documentation.

Important: Note that you’ll probably need to inspect the requests for a complete understanding and debugging.

one more thing

Not very close to this feature but valuable, the dataClass.getCount() function is now available to get the number of entities in a dataclass.

This avoids calling dataclass. all().length builds an entity selection on the server and fully loads the first entity on the client.

var $count : Integer


now play with the HDI and the summit 2020 demo

Download the HDI and the Summit 2020 session demo to learn more!



• Product Owner •

Marie-Sophie Landrieu-Yvert has joined the 4D Product team as a Product Owner in 2017. As a Product Owner, she is in charge of writing the user stories then translating it to functional specifications. Her role is also to make sure that the feature implementation delivered is meeting the customer need.

Marie-Sophie graduated from the ESIGELEC Engineering School and began her career as an engineer at IBM in 1995. She participated on various projects (maintenance or build projects) and worked as a Cobol developer. Then she worked as an UML designer and Java developer. Lately her main roles were analyzing and writing functional requirements, coordinate business and development teams.