Guide for Mobile Services Cockpit
This guide provides further details to SAP Note 3697481. Follow the step-by-step instructions for replacing credential types from instance-secret to binding-secret via Mobile Services Cockpit. This process is essential for maintaining compatibility with updated security requirements in SAP BTP environments.
Overview
When XSUAA service instances use the unsupported instance-secret credential type, they need to be updated to use binding-secret instead. This process involves identifying affected instances, deleting the problematic service keys, and restoring the mobile service instances through the Mobile Services Cockpit.
High-Level Flow
- Manually identify XSUAA instances with unsupported credential type
- Delete affected service key
- Restore mobile service instance via Mobile Services Cockpit
Step 1: Manually Identify XSUAA Instances with Unsupported Credential Type
1.1 Access BTP Cockpit
- Log in to the BTP Cockpit on your subscriber subaccount
- Navigate to the “Service Instances” section by going to Services → Instances
1.2 Filter for Authorization & Trust Management Services
- Select “Authorization & Trust Management” from the service type filter to display only XSUAA instances
1.3 Inspect Service Keys
- Click on the relevant XSUAA service instance to open its detail view
- Navigate to the “Service Keys” section within the service detail view
- Examine the credential type for each service key
1.4 Identify Problematic Keys
- Look for service keys with credential type “instance-secret”
- These service keys need to be deleted and recreated
Note: Service keys with instance-secret credential type are no longer supported and must be replaced with binding-secret type.
Step 2: Delete Affected Service Key
2.1 Navigate to Service Keys Section
- In the XSUAA service detail view, ensure you’re in the “Service Keys” section
- Locate the service key with the “instance-secret” credential type
2.2 Delete the Service Key
- Select the service key with the “instance-secret” credential type
- Click on the “Delete” button to remove the affected service key
2.3 Confirm Deletion
- Confirm the deletion when prompted by the system
- Wait for the deletion process to complete
Important: This will cause a temporary state change to “INCONSISTENT” for the mobile service instance until the application is restored in the next step.
Step 3: Restore Mobile Service Instance via Mobile Services Cockpit
3.1 Access Mobile Services Cockpit
- Log in to the Mobile Services Cockpit
- Navigate to the Native/MDK mobile apps list view by going to Mobile Applications → Native/MDK
3.2 Trigger Consistency Check
- In the browser URL bar, replace the /index.html#/page.apps.native part with /apps
- This action triggers a consistency check of the mobile services instances in your space
3.3 Return to Native/MDK Apps View
- Navigate back to the Native/MDK mobile apps list view
- Use the browser’s back button or navigate via Mobile Applications → Native/MDK
3.4 Locate Inconsistent Instances
- Manually refresh the list view (using browser refresh or the refresh button)
- Continue refreshing until affected instances show “INCONSISTENT” state
- Look for mobile service instances that have changed to this state
3.5 Open Instance Detail View
- Select the affected mobile service instance with the “INCONSISTENT” state
- Click on the instance to open its detail view
3.6 Restore the Instance
- In the instance detail view, locate and click the “Restore” button
- This will initiate the restoration process for the mobile service instance
3.7 Verify Restoration
- Refresh the detail view after a few moments
- Confirm that the state has changed back to “RUNNING”
- The instance should now be using the correct binding-secret credential type
Important Notes
- Repeat the above steps for each affected XSUAA service key identified in Step 1
- The restoration process may take several minutes to complete
- Monitor the instance status carefully to ensure successful restoration
- If an instance remains in “INCONSISTENT” state for an extended period, contact support
Summary
This process ensures that your mobile service instances use the supported binding-secret credential type instead of the deprecated instance-secret type. The temporary inconsistent state is expected and resolved through the restoration process in the Mobile Services Cockpit.
For additional support or questions regarding this process, consult your SAP BTP administrator or contact SAP Support.
Guide for Mobile Services CockpitThis guide provides further details to SAP Note 3697481. Follow the step-by-step instructions for replacing credential types from instance-secret to binding-secret via Mobile Services Cockpit. This process is essential for maintaining compatibility with updated security requirements in SAP BTP environments.OverviewWhen XSUAA service instances use the unsupported instance-secret credential type, they need to be updated to use binding-secret instead. This process involves identifying affected instances, deleting the problematic service keys, and restoring the mobile service instances through the Mobile Services Cockpit.High-Level FlowManually identify XSUAA instances with unsupported credential typeDelete affected service keyRestore mobile service instance via Mobile Services CockpitStep 1: Manually Identify XSUAA Instances with Unsupported Credential Type1.1 Access BTP CockpitLog in to the BTP Cockpit on your subscriber subaccountNavigate to the “Service Instances” section by going to Services → Instances1.2 Filter for Authorization & Trust Management ServicesSelect “Authorization & Trust Management” from the service type filter to display only XSUAA instances1.3 Inspect Service KeysClick on the relevant XSUAA service instance to open its detail viewNavigate to the “Service Keys” section within the service detail viewExamine the credential type for each service key1.4 Identify Problematic KeysLook for service keys with credential type “instance-secret”These service keys need to be deleted and recreatedNote: Service keys with instance-secret credential type are no longer supported and must be replaced with binding-secret type.Step 2: Delete Affected Service Key2.1 Navigate to Service Keys SectionIn the XSUAA service detail view, ensure you’re in the “Service Keys” sectionLocate the service key with the “instance-secret” credential type2.2 Delete the Service KeySelect the service key with the “instance-secret” credential typeClick on the “Delete” button to remove the affected service key 2.3 Confirm DeletionConfirm the deletion when prompted by the systemWait for the deletion process to complete Important: This will cause a temporary state change to “INCONSISTENT” for the mobile service instance until the application is restored in the next step.Step 3: Restore Mobile Service Instance via Mobile Services Cockpit3.1 Access Mobile Services CockpitLog in to the Mobile Services CockpitNavigate to the Native/MDK mobile apps list view by going to Mobile Applications → Native/MDK 3.2 Trigger Consistency CheckIn the browser URL bar, replace the /index.html#/page.apps.native part with /appsThis action triggers a consistency check of the mobile services instances in your space 3.3 Return to Native/MDK Apps ViewNavigate back to the Native/MDK mobile apps list viewUse the browser’s back button or navigate via Mobile Applications → Native/MDK 3.4 Locate Inconsistent InstancesManually refresh the list view (using browser refresh or the refresh button)Continue refreshing until affected instances show “INCONSISTENT” stateLook for mobile service instances that have changed to this state 3.5 Open Instance Detail ViewSelect the affected mobile service instance with the “INCONSISTENT” stateClick on the instance to open its detail view3.6 Restore the InstanceIn the instance detail view, locate and click the “Restore” buttonThis will initiate the restoration process for the mobile service instance 3.7 Verify RestorationRefresh the detail view after a few momentsConfirm that the state has changed back to “RUNNING”The instance should now be using the correct binding-secret credential typeImportant NotesRepeat the above steps for each affected XSUAA service key identified in Step 1The restoration process may take several minutes to completeMonitor the instance status carefully to ensure successful restorationIf an instance remains in “INCONSISTENT” state for an extended period, contact supportSummaryThis process ensures that your mobile service instances use the supported binding-secret credential type instead of the deprecated instance-secret type. The temporary inconsistent state is expected and resolved through the restoration process in the Mobile Services Cockpit.For additional support or questions regarding this process, consult your SAP BTP administrator or contact SAP Support. Read More Technology Blog Posts by SAP articles
#SAPCHANNEL