Couldn't update service instance '-uaa' due to issue with a jobscheduler

[vera-lazouskaya]

Issue description

Hello,

I found the following issue, after renaming of jobscheduler instance once, if the old name is reverted back, xs-security.json config can't be applied to xsuaa service.
An example, we renamed ccflex-jobscheduler to jobscheduler and back to ccflex-jobscheduler.
After that the following syntax of xs-security.json does not work.
{
"name": "$XSAPPNAME.JOBSCHEDULER",
"description": "Job Scheduler Scope",
"grant-as-authority-to-apps": [
"$XSSERVICENAME(ccflex-jobscheduler)"
]
}

We repeated the same with another name ccflex-jobs -> ccflex-jobscheduler -> ccflex-jobs

And the error is following:
Error updating application null (Error parsing xs-security.json data: Error reading space ID for service instance 'ccflex-jobs' from cloud controller: '404 Not Found: "{"errors":[{"detail":"Service instance not found","title":"CF-ResourceNotFound","code":10010}]}"')

How can we fix it without deletion of scheduler and recreation of it, since it's time consuming to create all jobs manually?

Feedback Type (Optional)

None

Page Title on SAP Help Portal (prefilled)

What Is SAP Job Scheduling Service?

Page URL on SAP Help Portal (prefilled)

https://help.sap.com/docs/PRODUCT_ID/07b57c2f4b944bcd8470d024723a1631/22c2df4d22cb4a05af4c9502a67597ae.html?state=PRODUCTION&version=Cloud&locale=en-US

[danachkov]

Hi, @vera-lazouskaya. Thank you for reporting this case. We’ll look into it and come back to you if we have any questions.

[nikolaydrm]

Hello @vera-lazouskaya -

Why is the name of the service instance important in your setup?

it's time consuming to create all jobs manually?

https://community.sap.com/t5/technology-blog-posts-by-sap/sap-job-scheduling-service-migrate-jobs-amp-schedules-from-one-instance-to/ba-p/14138678 addresses the automated approach of export/import of jobs&schedules from one instance to another.

[vera-lazouskaya]

@nikolaydrm It’s important for us that the configuration of the XSUAA service with the correct name of the scheduler service does not cause deployment failures, and that it remains consistent across production, test, and development environments. The configuration should be identical in all environments.

Previously, the service in QA was renamed by mistake, and after reverting the name back, the configuration stopped working.

Thank you for providing the script. However, I’m not sure how to use it: if there can only be one service instance in an environment, it seems impossible to have both the source and target services in the same environment at the same time.

We could try recreating the service, but we’re unsure if it will work afterward. The core issue is that it’s unclear why the service becomes invisible after renaming.