Here’s a complete solution for handling OAuth2 token management in long-running batch processes:
Architecture Overview
Implement a TokenManager class that encapsulates all token lifecycle operations - acquisition, refresh, validation, and renewal. This centralizes token logic and makes your batch processing code cleaner.
Token Manager Implementation Pattern
class TokenManager {
String accessToken;
String refreshToken;
long expiresAt;
synchronized String getValidToken() {
if (System.currentTimeMillis() >= expiresAt - 300000) {
refreshAccessToken();
}
return accessToken;
}
}
Key aspects:
- Store access token, refresh token, and calculated expiration timestamp
- Check validity before each use (5-minute buffer: 300000ms)
- Synchronize token operations for thread safety
- Return valid token or refresh automatically
OAuth2 Token Refresh Process
When refreshing, make a POST request to the token endpoint:
Endpoint: https://your-instance.fa.us2.oraclecloud.com/oauth/v1/token
Required parameters:
- grant_type: “refresh_token”
- refresh_token: your current refresh token
- client_id: your integration app client ID
- client_secret: your integration app secret
The response includes:
- access_token: new access token (valid 3600 seconds)
- refresh_token: NEW refresh token (use this for next refresh)
- expires_in: validity duration in seconds
- token_type: “Bearer”
Critical Implementation Details
-
Always Update Refresh Token: Each refresh response contains a new refresh token. Your old refresh token becomes invalid immediately. Update your stored refresh token with each successful refresh.
-
Calculate Expiration Time: Don’t rely on expires_in alone. Calculate absolute expiration: expiresAt = System.currentTimeMillis() + (expires_in * 1000) - 300000. The 300000ms (5 minutes) buffer ensures you refresh before actual expiration.
-
Batch Processing Strategy: For your 2-3 hour asset import job processing 4,200 records, check token validity every 100-200 records rather than per record. This balances token freshness with performance overhead.
-
Error Handling: Implement retry logic for token refresh failures:
- Network timeout: Retry with exponential backoff (2s, 4s, 8s)
- 401 Unauthorized: Refresh token expired - perform full re-authentication
- 429 Rate Limit: Wait and retry (Oracle typically allows 2000 requests/hour)
- 500 Server Error: Retry after delay
-
Middleware Integration Pattern:
// Pseudocode - Asset import batch process:
1. Initialize TokenManager with initial authentication
2. For each batch of 200 asset records:
a. Get valid token from TokenManager
b. Make REST API calls with token in Authorization header
c. Handle API responses and log results
3. TokenManager automatically refreshes when needed
Initial Authentication
For the first token acquisition, use client_credentials grant:
- grant_type: “client_credentials”
- scope: Asset Management API scope
- client_id and client_secret
Store both access and refresh tokens from this initial response.
Monitoring and Logging
Implement comprehensive logging:
- Token acquisition timestamp
- Token refresh events with old/new expiration times
- Refresh failures with error details
- API call failures due to token issues
This helps diagnose integration problems quickly. We set up alerts when token refresh failure rate exceeds 5% in any hour.
Rate Limiting Considerations
Oracle Fusion Cloud enforces rate limits on both token endpoints and REST APIs. For token refresh specifically:
- Limit: ~100 refresh requests per hour per client
- Your 4-hour batch with hourly token refresh uses only 4 requests
- Proactive refresh prevents rate limit issues
Production Best Practices
-
Connection Pooling: Reuse HTTP connections for token and API calls to reduce overhead
-
Graceful Degradation: If token refresh fails after retries, log detailed error, save batch progress, and exit gracefully. Resume from last successful checkpoint on next run.
-
Token Storage: For distributed middleware, consider storing tokens in Redis or similar cache with expiration TTL matching token lifetime. This enables multiple workers to share tokens.
-
Testing: Create unit tests that simulate token expiration mid-batch to verify refresh logic works correctly.
Specific to Your Scenario
Given your 2-3 hour batch processing 4,200 assets:
- Initial auth at job start: 0 hours
- First token refresh: ~55 minutes (before 1-hour expiration)
- Second token refresh: ~1 hour 55 minutes
- Possible third refresh: ~2 hours 55 minutes (if job approaches 3 hours)
This ensures continuous operation without authentication failures. Your middleware should handle 2-3 token refreshes maximum per batch run, well within rate limits.
Implementing this pattern will eliminate your 401 errors and make your asset import integration robust for long-running batch operations.
This draft is based on general Oracle Fusion Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.