Our demand planning batch jobs run through AIS Orchestrator and have started failing intermittently since upgrading to 9.2.1. The jobs are scheduled to run every 4 hours, but we’re seeing failures after the first successful run each day.
The error indicates SSO token expiry, but the jobs are triggered by Orchestrator which should handle authentication automatically. We’re using enterprise SSO with a 6-hour token lifetime, so theoretically the token should survive multiple job cycles.
Orchestrator Error Log:
SSO token expired at 13:47:22
Job: DemandPlanningRefresh failed
Retry attempt: 0 of 3
The first job at 06:00 succeeds, but the 10:00 and 14:00 runs fail with expired tokens. Manual job triggers work fine. Has anyone configured token refresh strategies for Orchestrator batch scheduling? Missing these planning cycles is causing downstream forecasting issues.
Be careful with OAuth client setup for Orchestrator. The client needs specific scope: ‘orchestration:execute’ plus any data service scopes your demand planning jobs require. For demand planning, that’s likely ‘ais:read’ and ‘ais:write’ at minimum.
Also configure token refresh interval in Orchestrator settings. Default is 3600 seconds (1 hour), but you can adjust based on your job patterns. For 4-hour recurring jobs, setting refresh to 3000 seconds ensures tokens refresh before expiry even if a job runs longer than expected.
One gotcha: Orchestrator caches OAuth tokens per client ID. If you have multiple Orchestrator instances (HA setup), each needs its own client ID or they’ll fight over token refresh timing.
Unfortunately, you can’t change authentication method on existing scheduled jobs. Orchestrator stores authentication context at job creation time. You’ll need to export your orchestration definition (XML), delete the existing schedule, then reimport and reschedule using your new OAuth-authenticated session.
The good news is the orchestration logic itself doesn’t change - only the schedule. Export from Orchestrator Studio, verify the XML contains your complete workflow, then recreate the schedule while authenticated with OAuth credentials.
Don’t recreate jobs - that’s maintenance nightmare. Configure Orchestrator to use OAuth client credentials instead of SSO tokens for batch workloads. In your Orchestrator configuration, set authentication mode to ‘OAuth’ and specify a service account client ID/secret.
The OAuth tokens have programmatic refresh capabilities that SSO tokens lack. Your batch jobs will authenticate using client credentials flow, which generates tokens valid for the job duration and can refresh automatically if the job runs long.
You’ll need to register an OAuth client in JDE specifically for Orchestrator batch operations. Make sure it has the necessary permissions for demand planning orchestrations.
That explains the pattern. So for our 4-hour recurring jobs, the first run uses a fresh token but subsequent runs hit the expiry wall. What’s the recommended approach - should we recreate the Orchestrator job schedule with each run, or is there a way to configure Orchestrator to use service account tokens instead of SSO?
I’ve registered the OAuth client and updated Orchestrator config to use OAuth authentication. The token refresh interval is now set to 3000 seconds. However, I’m unclear on how to update the existing scheduled job to use the new OAuth authentication instead of the old SSO token.
Do I need to delete and recreate the schedule, or is there a way to update the authentication method on existing jobs? Our job has complex dependencies and I’d prefer not to rebuild the entire orchestration if possible.