Integration Scenarios

This section outlines typical integration scenarios that are frequently implemented using the PQFORCE API. The examples focus on common business requirements and illustrate how PQFORCE can be embedded into an existing system landscape. The scenarios described below are not exhaustive, but they highlight proven integration patterns and key considerations when designing interfaces.

Import of Budget and Actual Project Costs from an ERP System

A common integration scenario is the import of budgeted and actual project costs from an ERP system into PQFORCE. In many customer environments, this type of integration is implemented as a file-based interface, using structured data formats such as JSON or XML.

In this scenario, the ERP system periodically exports cost data into files that are placed on a designated shared drive within the customer’s IT infrastructure. An integration component monitors this location and processes new or updated files once per day. During processing, the Agent parses the file contents, validates the data, and maps ERP cost structures to the corresponding PQFORCE object types, such as projects and cost positions.

The PQFORCE API is then used to create or update the relevant objects, ensuring that budget and actual cost information is correctly historized. Because the integration runs in a controlled, scheduled manner, this approach is well suited for high data volumes and for scenarios where near-real-time synchronization is not required. Proper error handling, logging, and reconciliation mechanisms are essential to ensure data consistency between the ERP system and PQFORCE.

Import of Reported Times from a Time Recording System

Another frequently used integration scenario is the import of stamped working times from an external time recording system. Unlike ERP cost imports, this scenario typically relies on direct REST-based communication between systems.

In this setup, the time recording system either actively pushes time entries to PQFORCE or is polled periodically by an integration service that retrieves newly recorded or modified time data. The integration logic transforms the time entries into the corresponding PQFORCE object representations and submits them via the API. Each time entry is usually linked to a resource and the corresponding ActualPeriod.

Because time data often changes frequently and may need to be reflected promptly for reporting or controlling purposes, this integration is commonly executed multiple times per day or near real time (action triggered). Care must be taken to handle updates, corrections, and deletions of time entries in a way that aligns with PQFORCE’s historization model. Using stable external identifiers or third-party references is strongly recommended to ensure reliable synchronization.

Export of Consolidated Portfolio Data to Microsoft Power BI

PQFORCE is often used as a central planning and consolidation platform, making it a natural data source for reporting and analytics tools such as Microsoft Power BI. In this integration scenario, consolidated portfolio, project, time, and cost data is exported from PQFORCE and consumed by Power BI for visualization and analysis.

Typically, an integration service queries the PQFORCE API at regular intervals to retrieve the relevant data sets. This may include hierarchical portfolio structures, aggregated project metrics, time and cost summaries, and selected object properties. The retrieved data is then transformed into a tabular format suitable for Power BI and either stored in an intermediate data store or exposed directly via a data connector.

Given the potentially large data volumes involved, this scenario often makes extensive use of batch endpoints, filtering, and incremental data extraction strategies. Since Power BI is primarily a read-only consumer, the integration focuses on efficient data retrieval and consistency rather than transactional updates. Ensuring a clear separation between operational data in PQFORCE and analytical models in Power BI helps maintain performance and scalability on both sides.