I’ve run into an interesting scenario. I have an HTTP endpoint I need to call with a Web Services connector. The endpoint HTTP operation is a DELETE. Because it is a DELETE, the API is not expecting a payload/body, which makes sense. The issue is that if there are no headers defined for the operation in the source configuration, the connector will automatically add a Content-Type header with value application/json. This causes the endpoint to throw a 415 Unsupported Media Type which makes total sense because it’s not expecting a payload, yet the connector is basically forcing the API to think we are sending one because of the Content-Type header. To make it even worse, it’s doing this AFTER the WebServicesBeforeOperation rule runs, so I cannot null out the headers with that rule. I’ve verified this via the ccg logs.
Has anyone else run into this and found a workaround? A guess a possible workaround is executing the DELETE in the before rule, but is a bit of a hack. I get that SailPoint is trying to reduce human error by automatically adding the header as it makes sense in a lot situations, but they simply just shouldn’t be doing that at the same time. It’s a bad assumption.
When you say it’s a bit of a hack - I could be reading it wrong, but it looks like delete account isn’t supported out of the box and a before rule is recommended (from HTTP Operations). That’s from the VA based Web Services Connector.
However, just noticed that delete account is supported in the SaaS Web Services Connector, with the interesting note: “If you wish to exclude the default Content-Type header from the requests, please add removeDefaultHeaderFromRequest:true in the connectionParamater object”
@j_place Keep in mind I am just talking about using an HTTP DELETE, doesn’t mean it’s necessarily tied to an account Delete operation (although in this case it is, and I am using a BeforeProvisioning rule to accomplish this…). Thanks for finding this on the SaaS Web Services connector. Unfortunately I am using the VA based Web Services connector, but it’s good to know this workaround is built into the other version. I ended up executing the DELETE in the WebServicesBeforeOperation rule (where I did not add any headers) and then just allowing HTTP 415 to be an allowed success code on the actual configured delete call on the source.