- Erste Schritte
- Lizenzierung
- Einstellung und Konfiguration (Setup and Configuration)
- Verwenden des Dienstes
- Entity types
- Erstellen einer Entität
- Entities in VS Code
- Anpassen einer Entität
- Verwalten der Daten für eine Entität
- Erstellen von Beziehungen
- Auswahlsätze
- Systembenutzerentität
- Schema-Export und -Import
- Erweiterte Suche in Entitätsdaten
- Query limits for external data
- Entity modeling and querying best practices
- Entities in Solutions
- Bekannte Einschränkungen
- Referenz (Reference)
- Beispiele und Tutorials
- Protokollierung
Modeling and query guidance for Data Fabric / Data Service entities: business object scope, cross-entity queries, filters, query volume, and transaction scope.
An entity in Data Fabric / Data Service represents a single business object. The practices on this page keep entity schemas aligned to that boundary, and keep queries within the volumes that the platform and its source systems handle reliably.
Which practices apply to a given entity depends on whether it is Native or Federated. For the difference between the two, refer to Entity types.
| Practice | GiltFür |
|---|---|
| One entity per business object | Native and Federated |
| Joins across business objects | Native and Federated |
| Filters and aggregates at the source | Native and Federated |
| Federated query volume | Federated |
| Transaction scope | Nativ |
One entity per business object
An entity is designed to represent a business object, and each entity stays limited to one. A single entity should not embed several business objects, and it should not model an entire business process.
Where a business process spans several business objects, each object belongs in its own entity, and the connections between them are modeled as relationships. For how relationships are defined, refer to Creating relationships.
Joins across business objects
A single automation often needs data from more than one business object. Rather than widening one entity to hold them all, the Query Multiple Entity Records activity provides one interface that fetches data across several entities.
Filters and aggregates at the source
Native and Federated entities both support filters and aggregates. Depending on the interface in use, the platform accepts SQL-style WHERE clauses or OData filter queries, along with aggregate functions including SUM, COUNT, and AVG.
Leaving this work to the platform, rather than performing it inside an automation, has three effects:
- Less data moves at runtime.
- Query performance improves.
- The logic coded into the automation stays simpler.
Federated query volume
A query over a Federated entity reads from a live system of record, such as Workday, Salesforce, or SAP. Those systems do not deliver consistently reliable performance when a transactional request fetches a large volume of data, and Data Fabric / Data Service entities are designed for transactional use cases.
A filter that holds each query under 50 MB of fetched data keeps the request within the range these sources serve reliably. The limits the platform itself enforces on queries that read external data are documented in Query limits for external data.
Transaction scope
Data Fabric / Data Service provides ACID-compliant transactions, meaning atomic, consistent, isolated, and durable, scoped to a single Native entity.
An operation that modifies several Native entities has no platform-level transaction covering it as a unit. Where a use case requires that guarantee, the transaction semantics are handled in the application or automation layer.