Looking to gather insights on best practices for maintaining audit trail completeness when integrating external systems with Aras 12.0 via REST API. Our regulatory requirements demand full traceability of all data changes, including those made through API calls.
We’re debating between two approaches: direct API calls with custom audit logging versus using a middleware layer that ensures audit trail completeness before forwarding requests to Aras. The challenge is maintaining regulatory traceability while keeping the integration performant.
Has anyone implemented API-based integrations for compliance-critical environments? What patterns worked best for ensuring audit trails capture all necessary information including the originating system, user context, and business justification for changes? I’m particularly interested in how others have handled the trade-off between direct API efficiency and middleware-based audit control.
Consider using Aras’s built-in History tracking combined with custom properties for audit context. We extended standard ItemTypes with audit_source, audit_user_context, and business_justification properties. Our API clients populate these fields in every request. Aras History automatically captures the changes, and our custom properties provide the additional context needed for compliance. This approach leverages Aras’s native audit capabilities rather than building parallel audit systems. We query History items for compliance reports, which works well for our ISO 13485 audits.
We implemented a middleware approach for our FDA-regulated environment. The middleware validates all API requests, enriches them with audit metadata (originating system, business context, timestamps), and then forwards to Aras. This gives us a centralized audit control point. The performance overhead is minimal - about 50-100ms per request - which is acceptable for our compliance requirements. The key benefit is that we can enforce audit policies consistently across all integration points without modifying each calling system.
From an enterprise architecture perspective, the middleware approach provides better separation of concerns and makes it easier to adapt to changing regulatory requirements without touching Aras configuration. We’ve implemented audit middleware using Azure API Management with custom policies that log all requests to Azure Monitor and enrich the Aras API calls with audit metadata. This also gives us the flexibility to route requests through different audit paths based on data classification. The middleware can enforce pre-flight validation to reject requests that don’t meet audit requirements before they even reach Aras.
I’d recommend direct API with server-side Methods in Aras to capture audit data. We use onBeforeAdd/onBeforeUpdate Methods that extract audit context from HTTP headers and write to custom audit tables. This keeps the integration simple while ensuring Aras controls the audit logic. The calling systems just need to include context headers like X-Source-System and X-Business-Justification. Performance is excellent since everything happens in one transaction, and we avoid the complexity of maintaining middleware infrastructure.
Don’t overlook the authentication and authorization aspects of API audit trails. We use OAuth2 with JWT tokens that include claims for source system, actual user identity, and authorization scope. These claims are automatically logged by Aras’s authentication layer. Combined with server-side Methods that write to custom audit tables, this provides comprehensive audit trails. The JWT approach means audit context travels with every request without additional headers, and it’s cryptographically verifiable. This has passed multiple security audits for our medical device PLM implementation.