[
https://issues.apache.org/jira/browse/CAMEL-22782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Ross resolved CAMEL-22782.
---------------------------------
Assignee: Jeremy Ross
Resolution: Fixed
> 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
> Assignee: Jeremy Ross
> Priority: Major
> 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)
