In-Depth Explanation: Execution of OData Requests

There are three main types of requests possible:

1. OData GET request to an OData Service
2. OData GET request to an entity of an OData Service
3. OData precalc (POST or GET)

OData GET Request to an OData Service

When OData GET requests are done, the OData Service in the Fabasphere is loaded and the needed information about the OData schema are calculated. The result is a valid OData overview.

OData GET Request to an Entity of an OData Service

On such a request, actually data is loading from the Fabasphere and given back in OData style.

The whole process can be split up in these parts:

1. Generating the schema.
2. Calculating the cube.
3. Getting the attribute values.
4. Building the OData response.

Especially the second and the third step can be performance critical, so these are described in more detail.

Calculating the Cube

Given an entity defined in the OData Service as “Found Objects”, two queries to the Fabasphere are done to fetch the data:

First a query is done which looks up all Teamrooms in the given context (room, configuration or organization). This list of Teamrooms is then used in the second query, which looks up objects of the entity type which are in the given list of Teamrooms.

Important: Please be careful here about limits: if your selected context (room, configuration or organization) has a lot of Teamrooms (10 000+), this can cause the second query which is an IN-Query, to not run performant or not run at all because of too many IN-values. Please consider here defining your own query for this entity!

Getting the Attribute Values

In parallel running threads/processes, the wanted attributes are loaded. On performance issues please check out the performance chapter.

OData Precalc (POST or GET)

The OData precalc endpoints manage the asynchronous pre-calculation of OData service definitions. They allow users to trigger data processing in the background and monitor execution status.

GET Requests: Status Monitoring

GET requests retrieve live status information for pre-calculation tasks. The response details vary based on the endpoint structure:

• Service-Level Status
  Sending a GET request to /odata/precalc/{cooid} returns the execution status of all current jobs calculating data for that specific OData service definition.
• Job-Level Status
  Sending a GET request to /odata/precalc/{cooid}/{id} returns detailed metrics and status for that specific background job instance.

An empty response indicates that all associated job information related to the service definition has been automatically removed after the system configured TTL of the status information.

POST Requests: Triggering Execution

Sending a POST request to /odata/precalc/{cooid} initiates the pre-calculation workflow for the specified OData service definition. The endpoint immediately returns a unique job ID ({id}), while the actual calculation runs asynchronously in the background.

• Processing
  The system processes the service definition and calculates all associated entities.
• Storage
  The calculated data is saved to the Teamroom defined in the OData service configuration.

Concurrency and Cache Behavior

If multiple POST requests are sent for the same OData service definition ({cooid}), the system generates multiple distinct background jobs.

• Execution
  These jobs process the pre-calculations concurrently across different threads.
• Storage Impact
  The parallel jobs overwrite the same shared cache destination in the cloud.