Troubleshooting

Problem description

There are various part types which are processed on the production line repeatedly, leading to an excessive number of entries in the quality database. This behavior causes the content of the Part Protocol growing to a size where it cannot be displayed any longer due to a timeout of the browser.

Proposed solution

Ensure that the Part ID for this component is not reused too frequently. Instead, update the Part ID as needed to prevent an excessive accumulation of entries in the quality database.

Problem description

When a scope is created via the API and a part telegram is sent to the Data Collector Service within one second, the caching mechanism (which updates once a second) may inadvertently return the default_config Scope. This issue is most likely to occur in cases where API calls are part of automated tests of modules integrating Part Traceability’s APIs.

Proposed solution

Introduce a delay or verify timestamps to ensure that the cache has been updated before processing the part telegram after the new scope is created.

Problem description

The SAP Pallet Number or SAP Box Number are not displayed in the Result List of Packaging Information, even though the information has been sent to Part Traceability and has been persisted in the database.

Proposed solution

Ensure packaging data for a single Part ID has matching types:

Problem description

The Pallet Package ID or Box Package ID is not displayed in the Result List of Packaging Information, even though the information has been sent to Part Traceability and has been persisted in the database.

Proposed solution

The data sent must set a relation between the result id and a childPackageId. There is no need to set a relation between the result id and a partID.

Problem description

When using the ReadLocationCounter functionality in Data Browser Service’s public API QueryRds endpoint, passing a locationPath parameter (starting with "LINE…​") results in an error. The API only accepts locationId parameters for retrieving counter data. The current implementation does not support path-based location references.

Proposed solution

Use only numeric location identifiers (locationId) instead of location paths when calling ReadLocationCounter. Any locationPath parameters must be converted to their corresponding locationId values before making the API call.

Problem description

A database connection string cannot be reused across multiple scopes, as this leads to conflicts and unpredictable behavior in the system. Each scope requires its own dedicated connection string to maintain proper data isolation and system stability.

Proposed solution

For production environments, ensure each scope has a unique connection string. For testing purposes, duplicate the connection in _Part Traceability > Configuration > Connection Management and modify the connection string by appending RETRY_DELAY=3 to create a distinct connection identifier while maintaining the same underlying database connection parameters.