Re-deployment fails because of managed service sap-successfactors-extensibility

[piejanssens]

Service operation failed: Controller operation failed: 502 Updating service "my-sfsf-end-user" failed: Bad Gateway: CF-ServiceBrokerBadResponse(10001): Service broker error: Service broker s4-service-broker failed with: Internal server error 

I assume this is because some underlying logic that is creating the destination and cannot handle the fact that the destination with that name already exists: can you please check this internally?

Is this the reason you have used org.cloudfoundry.existing-service and put it in comments?

[jmsrpp]

Hi @piejanssens - thanks for trying out this repo. Yes, exactly. If you are using an existing service and don't want it to be reconfigured, please utilize org.cloudfoundry.existing-service and bind your application to the appropriate entries in either .env or by binding them manually in the UI. You can see the details here:

https://github.com/SAP-samples/successfactors-extension-calculate-employee-seniority/tree/mission/05-DeployCAPApplicationToCloudFoundryAndHANACloud#redeployment

[piejanssens]

Good to know, thanks.

I would prefer to have that same behavior with sap-successfactors-extensibility than the other services, which means it would detect the instance exist already and show 'Updating service xxx'. Could you get in touch with the maintainer of that service to discuss this issue?

[jmsrpp]

Hi @piejanssens - we will do so. Originally we needed this alternate configuration for the Event Mesh and the Extensibility Service. Looks like Event Mesh now supports the setting, so we will follow up with the product owner of the extensibility service and check.

[jmsrpp]

Hi @piejanssens - confirmed that this is the current designed behavior for the extensibility service and I have raised an enhancement request to request this be added. Will close this issue but report back with further details. For now, please continue to utilize the workaround, as needed.

[nocin]

Hi @jmsrpp,

since this behavior still exists in 2023, do you have any updates on this? I have to say that the current behavior is really annoying when deploying an application in a new subaccount, and you always have to change the mta.yaml before. Also, it's not possible to change the systemName or technicalUser via cf update-service -c {"":""}.

Best regards Nico

[jmsrpp]

Hi @nocin,

The only update I can provide is from 1/18/23 when the request was accepted by the BTP development team responsible for this component. It is now in their backlog but doesn't yet have a target milestone. I'll provide your additional feedback and update this issue again once it is resolved.

Best, Jim

[piejanssens]

Hi @jmsrpp,

Upon deployment with "type: org.cloudfoundry.existing-service" we are now suddenly facing an error:

Yes, you are reading that right "s4-service-broker". I don't know where/why this is connected to the SuccessFactors Extensibility Service, but here we are. It's no longer working with "existing service". Can you please look into this?

@aspirio187 will test if redeployment is failing as well. In which case we are blocked.

Best regards,

Pieter

[aspirio187]

The redeployment fails indeed :

2023-11-14T12:02:37.7030924Z Proceeding with automatic retry... (3 of 3 attempts left) 2023-11-14T12:02:38.1212418Z Binding service instance "[SERVICE_INSTANCE_NAME]" to application "[APPLICATION_NAME]"... 2023-11-14T12:02:47.2411569Z Async operation for service binding between app "[APPLICATION_NAME]" and service instance "[SERVICE_INSTANCE_NAME]" failed with "10009 CF-UnableToPerform bind could not be completed: Service broker error: Service broker s4-service-broker failed with: Internal server error" 2023-11-14T12:02:47.2413718Z A step of the process has failed. Retrying it may solve the issue.

[jmsrpp]

Hi @piejanssens, @aspirio187, I am taking a look at this now.

[jmsrpp]

Hi,

I reproduced this and raised a bug ... @hterminasyan and I will keep an eye on it and let you know what can be done. In the short term, you can remove the extensibility service from your MTA for deployment and bind the service manually afterward. Not ideal but possible stopgap while we address this.

[jmsrpp]

Hi @piejanssens @aspirio187 - root cause of my issue was that I modified the underlying destination and it changed the ownership so that the binding failed. Can you confirm whether this is the case for you, as well? Can you please anyway create a new extensibility service and the automatic destination and update your binding? For me, I was successful with deployment after that. If not, please email me at james.rapp@sap.com with your CF region, global account id, and subaccount id.

[aspirio187]

@jmsrpp You are correct, once a change is done on the destination, the binding no longer works.

[hterminasyan]

@aspirio187 We raised an internal ticket, and our colleagues have added it to their backlog to provide a more precise error message (In this case, that is is not allowed to change the destination/ownership)

[supernaut42]

If you ever stumble on this: probably you have something wrong in your mta.yaml (I had a typo in the system name). If you delete the service instance manually in BTP cockpit, you'll receive a qualified error message.