Dayforce strongly recommends creating report definitions that are specifically designed for use with the OData feature. Doing so ensures that existing reports that are run in Dayforce aren't adversely impacted. It also ensures that the report definitions that are exposed to OData comply with the service’s expectations.
Considerations for Reports to Use with OData
The report definition must be accessible by the user’s default OData role. To modify role access, go to Reporting and Analytics > Reporting > Reports and click Edit > Properties.
- The report definition must have a Report Integration Name, which you set when you open the report by clicking Properties screen. The Report Integration Name is the report name that will be visible within the analytical tools when the user is presented with a list of reports to select from.
- Report definitions must be configured to provide raw data. Reports cannot use Groupings or Totals. This is by design because most analytical tools will not distinguish a grouping or total row from a regular data role, and users might inadvertently skew their data by including these rows in the analytical components.
- Sorting isn’t recommended. Dayforce recommends this approach to ensure the data retrieval process is as performant as possible. Most users will apply a sorting scheme that aligns with their use of the data within the analytical tool. Applying sorting within the report definition will result in the Dayforce reporting engine sorting the data prior to sending it to the requester via the OData connection, and the analytical tool applying the sorting scheme defined locally before allowing the requester to continue
- Column names cannot contain special characters.
- Default filtering of the report must be configured in a way that results in an optimized set of data being provided to the requester.
- Large data sets will impact performance.
- Depending on the analytical tools, certain types of filtering (for example, filtering for effective-dated information) might be too complicated for many users.
- Use relative dating features within report topics and report definitions to establish the filter criteria one time and avoid having to periodically revisit the criteria.
- Required parameters and filter conditions (in both report definitions and topics) must have default values. Optional filter conditions will be ignored when OData is requesting data from the reporting engine.
- Calculated and derived values should be handled by the requesting application and not within the report definition, except in the case that an expression needs to be used to secure a portion of the data. As an example, Birth Date usually shouldn't be available in reports because it contains the year of the employee’s birth. It is acceptable to create a derived field that returns only the month and day of the employee’s birth to ensure the year isn’t exposed.