Jeremy Ross created CAMEL-22782:
-----------------------------------
Summary: camel-salesforce: Modernize integration test setup with
Salesforce CLI
Key: CAMEL-22782
URL: https://issues.apache.org/jira/browse/CAMEL-22782
Project: Camel
Issue Type: Improvement
Components: camel-salesforce
Affects Versions: 4.16.0
Reporter: Jeremy Ross
Fix For: 4.17.0
h1. Summary
Migrate the Camel Salesforce component integration test infrastructure from
legacy Ant-based deployment to modern Salesforce CLI (sf), with improved
authentication, automatic environment setup, and better credential management.
h2. Problem
The existing integration test setup for camel-salesforce has accumulated
significant technical debt and friction that makes it difficult for developers
to run integration tests:
h2. Authentication Pain Points
- Security tokens required: Traditional username/password authentication
requires appending a security token to the password, which is confusing and
error-prone. This requires manual steps, involving logging into salesforce UI
and requesting a token be emailed.
- Manual credential management: Credentials are stored in
test-salesforce-login.properties which developers must manually configure. This
file is version-controlled with placeholder values that must be replaced.
- Connected app complexity: Tests require a custom Connected App to be deployed
with specific client ID/secret, adding another layer of configuration that
developers must understand and manage. Also requires manual steps after initial
metadata deployment to get OAuth client credentials and populate in
test-salesforce-login.properties.
h2. Deployment Tooling Issues
- Deprecated Ant tooling: The deployment uses ant-salesforce.jar (Salesforce
Migration Tool), which Salesforce has deprecated in favor of the Salesforce
CLI. The JAR must be manually downloaded and placed in
it/resources/migration-tool/.
- Metadata API format: The test metadata is stored in legacy metadata API
format rather than modern source format, making it harder to understand and
modify. Source format is the standard for all modern Salesforce development.
h2. Manual Setup Requirements
- Permission set not assigned: Tests require the Hard_Delete_Permission_Set for
bulk delete operations, but this must be assigned manually or via a
dynamically-executed Apex class (UpdateProfile.cls).
- Duplicate rules cause failures: Salesforce scratch orgs come with active
duplicate rules for Account, Contact, and Lead that cause test failures.
Developers must manually deactivate these rules.
- OAuth flow disabled by default: Newer Salesforce orgs have username/password
OAuth disabled by default. Developers must manually enable this in Setup before
tests can authenticate.
h2. Developer Experience Issues
- No scratch org support: Developers must have access to a persistent
Salesforce org configured specifically for testing. There's no easy way to spin
up a temporary test environment.
- Unclear error messages: When setup fails, error messages don't clearly
indicate what's wrong or how to fix it.
h1. Solution
h2. Modern Authentication
- Use refresh token flow with SF CLI's built-in PlatformCLI connected app - no
custom connected app deployment needed
- Automatically extract refresh token from SF CLI's stored authentication
- No security token required for scratch orgs
- Credentials stored in git-ignored .local/ directory
h2. Salesforce CLI Integration
- Replace Ant-based deployment with Salesforce CLI (sf command)
- Convert metadata from legacy format to source format (modern standard)
- Use exec-maven-plugin calling a shell script instead of embedded Ant tasks
h2. Automatic Environment Setup
- Permission set auto-assigned: Hard_Delete_Permission_Set assigned during
deployment
- Duplicate rules deactivated: Standard duplicate rules for Account, Contact,
Lead deployed as inactive
- OAuth flow enabled: Scratch org definition enables username/password OAuth
flow
- Connected app credentials auto-generated: On first deployment, credentials
are generated and cached
h2. Scratch Org Support
- Auto-create scratch orgs: If Dev Hub is authenticated and no credentials
provided, a scratch org is automatically created
- Org reuse: Scratch org becomes SF CLI's local default and is reused on
subsequent runs
- Zero-configuration for developers: Just authenticate to Dev Hub once, then
mvn verify -Pintegration handles everything
h1. Documentation
- it/resources/README.md - Complete setup guide with all options
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
