Operation mapping
- •salesforce:query (SOQL) → GET /services/data/vXX.0/query?q=...
- •salesforce:create → POST /services/data/vXX.0/sobjects/{type}
- •salesforce:update → PATCH /services/data/vXX.0/sobjects/{type}/{id}
- •salesforce:upsert → PATCH .../sobjects/{type}/{externalIdField}/{value}
- •salesforce:delete → DELETE /services/data/vXX.0/sobjects/{type}/{id}
Before and after: SOQL query
<salesforce:query config-ref="Salesforce_Config">
<salesforce:salesforce-query>SELECT Id, Name FROM Account</salesforce:salesforce-query>
</salesforce:query>webClient.get()
.uri(instanceUrl + "/services/data/v58.0/query?q={q}", "SELECT Id, Name FROM Account")
.headers(h -> h.setBearerAuth(accessToken))
.retrieve()
.bodyToMono(JsonNode.class)
.block();Authentication
The Mule Salesforce config's connection (username/password or connected-app OAuth) maps to a standard OAuth token flow: fetch a bearer token from the Salesforce token endpoint, cache it, and attach it to each request. Credentials live in configuration, not code.
How the conversion is validated
Salesforce is a hosted SaaS, so the generated integration is unit-tested at conversion time. When you run it in a pilot against your own Salesforce org, the same Proven-Parity comparison applies: your existing tests run against both the Mule app and the converted Spring Boot app, and every response field is scored MATCH or MISMATCH. We describe this precisely rather than claiming a live Salesforce sandbox was pre-tested.