モダンなSalesforce開発において、Lightning Web Component（LWC）は欠かせない技術要素となっています。しかし、多くの開発チームが「どのようなコーディング規約を設ければよいのか」「チーム全体で一貫したコードスタイルを維持するにはどうすればよいのか」といった課題を抱えています。

本記事では、SalesforceのApexコーディング規約の考え方を参考にしながら、LWC開発における実践的なコーディング規約の策定と活用方法について詳しく解説します。品質の高いLWCアプリケーションを開発するために、ぜひ本ガイドを参考にして、あなたのプロジェクトに最適なコーディング規約を構築してください。

本記事では、このテンプレートの特徴と効果的な活用方法について詳しく解説します。

なぜコーディング規約が重要なのか

1. フロントエンド開発の複雑性への対応

LWC開発では、JavaScript、HTML、CSS、そしてSalesforceのメタデータが複雑に絡み合います。統一されたコーディング規約がないと、以下のような問題が発生します：

• コンポーネント間でのスタイリングの不整合
• JavaScript のパフォーマンスの劣化
• コンポーネントの再利用性の低下
• デバッグの困難さ

2. Salesforceプラットフォーム特有の制約

LWC開発では、一般的なWebフロントエンド開発とは異なる独特の制約があります：

• Locker Service によるセキュリティ制約
• Lightning Data Service の効率的な活用
• イベント伝播とコンポーネント間通信
• レスポンシブデザインとLightning Design System（SLDS）の準拠

3. 長期保守性の確保

LWCコンポーネントは、Salesforceの組織内で長期間にわたって使用されます。初期開発から数年後の機能拡張や修正を考慮した、保守しやすいコード構造を保つことが重要です。

1.テーラリングガイド

１．目次サンプル

目次
1 はじめに 
　1.1 本書の目的 7
　1.1.1 利用者 7
1.2 記号 7
　1.2.1 本書で使用する記号についての説明 7
1.3 用語の定義 7
　1.3.1 本書で使用する記号についての説明 7
2 基本方針 8
　2.1 可読性の優先 8
　2.2 保守性の確保 8
　2.3 Lightning固有の考慮事項 8
3 命名規則 8
　3.1 コンポーネント名 8
　3.2 メソッド名 9
　3.3 定数名 10
4 ファイル構造とフォーマット 11
　4.1 ファイル構成 11
　4.2 インデント 11
　4.3 行の長さ 12
5 Javascript設計 13
　5.1 クラス構造の順序 13
　5.2 プロパティ設計 15
6 HTMLテンプレート設計 17
　6.1 テンプレート構造 17
　6.2 イベントハンドリング 18
7 CSSスタイル設計 21
　7.1 SLDS準拠 21
　7.2 CSSカスタムプロパティ 22
8 データアクセスとAPIコール 22
　8.1 Lightning Data Service (LDS) 22
　8.2 Apexメソッド呼び出し 24
9 イベント設計 25
　9.1 カスタムイベント 25
　9.2 プラットフォームイベント 27
10 テスト設計 28
　10.1 Jestテスト 28
　10.2 テストデータファクトリ 31
11 セキュリティとベストプラクティス 33
　11.1 セキュリティ考慮事項 33
　11.2 パフォーマンス最適化 34
12 国際化対応 36
　12.1 カスタムラベル使用 36
　12.2 日付・通貨・数値フォーマット 38
13 エラーハンドリング 40
　13.1 統一的なエラーハンドリング 40
　13.2 バリデーションエラー 43
14 デバッグとトラブルシューティング 45
　14.1 ログ出力 45
　14.2 パフォーマンス監視 46
15 コンポーネント設計パターン 48
　15.1 コンポーネント間通信 48
　15.2 コンポーネント間通信 50
16 メタデータ設計 53
　16.1 コンポーネントメタデータ 53
17 運用保守 55
　17.1 コードレビューチェックリスト 55

２.基本方針（可読性・保守性の重視）

テンプレートでは、「可読性の優先」「保守性の確保」「Salesforce固有の考慮事項」の3つを基本方針として掲げています。これらの方針は、長期的な開発・運用を見据えた重要な指針となります。

可読性の優先

• コードは書く時間よりも読む時間の方が長いことを念頭に置く
• 自己説明的なコードを心がける
• 適切なコメントで意図を明確にする

保守性の確保

• 単一責任原則に従ったコンポーネント設計
• 疎結合と高凝集を実現する構造
• 将来の変更に対応しやすい設計

パフォーマンスの重視

• 不要な再レンダリングを避ける
• 効率的なデータフェッチ
• 適切なライフサイクルフックの活用

３.命名規則の統一

3.1 コンポーネント名
規則:
• kebab-case（小文字、単語間はハイフン）
• 意味のある名前を使用
• 業務領域を表現する接頭辞を付ける

3.2 メソッド名
規則:
• camelCase（最初は小文字、以降の単語は大文字開始）
• 意味のある名前を使用
• Boolean型はis、has、canで開始

3.3 定数名
規則:
• UPPER_SNAKE_CASE（全て大文字、単語間はアンダースコア）
• 意味を明確に表現

4.ファイル構造とフォーマット

4.1 ファイル構成

my-component/

├── my-component.js         // Javascript ロジック

├── my-component.html       // HTML テンプレート

├── my-component.css        // CSS スタイル

├── my-component.js-meta.xml // メタデータ

└── __tests__/

    └── my-component.test.js // テストファイル

4.2 インデント

規則:

• 2スペースインデント（タブ文字は使用しない）
• 一貫したインデントレベルを維持

4.3 行の長さ

規則:

• 1行120文字以内を推奨
• 長い行は適切な位置で改行

5.Javascript設計

クラス構造体の順序、ﾌﾟﾛﾊﾟﾃｨ設計の規則と例を記述しています。

6.HTMLテンプレート設計

テンプレート構造、イベントハンドリングについての規約と例文について解説しています。

7.CSSスタイル設計

CSSスタイル設計のSLDS準拠について、CSSカスタムプロパティの利用方法について解説しています。

8 データアクセスとAPIコール

Lightning Data ServiceやApexメソッドの呼び出しに関する規則について解説しています。

8.1 Lightning Data Service (LDS)
規則:
• 単一レコード操作にはLDSを優先的に使用
• @wireでリアクティブなデータバインディング
• エラーハンドリングを適切に実装

8.2 Apexメソッド呼び出し
規則:
• @wireで自動データバインディング
• imperative callで手動データ取得
• 適切なエラーハンドリング

9.イベント設計

カスタムイベント、プラットフォームイベントについて解説

10.テスト設計

Jestテスト、テストデータファクトリについて解説

11.セキュリティとベストプラクティス

11.1 セキュリティ考慮事項
規則:
• ユーザー入力は常にサニタイズ
• lightning-formatted-textでXSS対策
• CRUD/FLS権限を考慮

その他

テンプレートを参照ください。

テンプレートの効果的な活用方法

1. プロジェクト開始時の規約策定

新しいSalesforceプロジェクトを開始する際、このテンプレートをベースとして、プロジェクト固有の要件に合わせてカスタマイズすることで、短時間で実用的なコーディング規約を策定できます。

活用手順：

1. テンプレートをダウンロードし、開発チーム全体で内容を確認
2. プロジェクトの特性に応じて、必要な項目を追加・修正
3. チーム内での合意形成とドキュメント化

2. 既存プロジェクトの品質改善

既に進行中のプロジェクトでも、段階的にコーディング規約を導入することで品質向上を図ることができます。

段階的導入のアプローチ：

• 第1段階: 新規開発コードから規約適用開始
• 第2段階: 既存コードの修正時に規約に合わせてリファクタリング
• 第3段階: 重要なモジュールから順次全面的な規約適用

3. コードレビューの効率化

テンプレートに含まれるチェックリストを活用することで、コードレビューの観点が明確になり、見落としを防ぐことができます。

4. 新人教育・オンボーディング

新しくチームに参加する開発者に対して、このテンプレートを教育資料として使用することで、Salesforce開発のベストプラクティスを効率的に伝えることができます。

実装時の注意点とコツ

段階的な導入を心がける

すべての規約を一度に導入しようとすると、開発チームに大きな負担をかけてしまいます。重要度の高い項目から順次導入し、チーム全体が慣れてから次の項目に進むことが重要です。

ツールを活用した自動化

可能な限り、IDE（Salesforce CLI、VS Code）の設定やCI/CDパイプラインを活用して、規約チェックを自動化しましょう。手動でのチェックに頼りすぎると、継続が困難になります。

定期的な見直しと改善

プロジェクトの進行に伴い、新たな課題や改善点が見つかることがあります。定期的に規約を見直し、チームの成長とプロジェクトの変化に応じてアップデートしていくことが大切です。

テンプレートに含まれる実践的なコード例

このテンプレートの大きな特徴の一つは、豊富な実装例が含まれていることです。抽象的な説明だけでなく、具体的なコード例を通じて「良い例」と「悪い例」を明示しているため、開発者が実際のコーディング時に迷うことなく適用できます。

SLDSの活用例

(css)
/*  良い例 - SLDS準拠 */
.account-container {
  padding: var(--lwc-spacing-medium);
}

.header {
  margin-bottom: var(--lwc-spacing-large);
}

.content {
  display: flex;
  flex-direction: column;
  gap: var(--lwc-spacing-medium);
}

.empty-state {
  text-align: center;
  padding: var(--lwc-spacing-x-large);
  color: var(--lwc-color-text-weak);
}

.error-message {
  color: var(--lwc-color-text-error);
  padding: var(--lwc-spacing-small);
  border: 1px solid var(--lwc-color-border-error);
  border-radius: var(--lwc-border-radius-medium);
  background-color: var(--lwc-color-background-error);
}

/* レスポンシブ対応 */
@media (max-width: 768px) {
  .content {
    padding: var(--lwc-spacing-small);
  }
}

継続的な品質向上のために

コーディング規約の導入は、ゴールではなくスタートラインです。継続的に品質を向上させるために、以下の取り組みを推奨します：

定期的なコードレビュー会の実施

チーム全体でコードレビューを行う時間を定期的に設け、規約の適用状況や新たな課題について議論します。

メトリクス測定と改善

テストカバレッジ、複雑度、規約違反数などのメトリクスを測定し、定量的な改善を図ります。

知識共有とベストプラクティスの蓄積

チーム内で発見されたベストプラクティスを規約に反映し、組織の知見として蓄積していきます。

まとめ

今回公開したSalesforce Apexコーディング規約テンプレートは、実際の開発現場での経験を基に作成された実践的なドキュメントです。このテンプレートを活用することで、開発チームは以下のメリットを得ることができます：

• 開発効率の向上: 統一されたコーディングスタイルにより、コードレビューや保守作業が効率化
• 品質の向上: Salesforce特有の制約を考慮したベストプラクティスにより、バグの削減と性能向上を実現
• チーム力の強化: 共通の規約により、チーム内でのコミュニケーションと協力が促進
• スケーラビリティの確保: 将来の機能拡張や保守作業に対応しやすいコード構造の実現

Salesforce開発の品質向上を目指すすべてのチームに、このテンプレートを積極的に活用していただき、より良いシステム開発を実現していただければと思います。

資料のダウンロード

テンプレートのダウンロードは、Creative Content Lab Tokyoの公式サイトから無料で行えます。ぜひ、あなたのプロジェクトでもご活用ください。

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

開発コーディング規約のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

最後に

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

Salesforce開発において、品質の高いコードを書くことは、システムの保守性、拡張性、そして開発チームの生産性に直結する重要な要素です。

しかし、多くの開発現場では「どのようなコーディング規約を設ければよいのか」「チーム全体で一貫したコードスタイルを維持するにはどうすればよいのか」といった課題を抱えています。

そこで今回、Creative Content Lab Tokyoでは、実際の開発現場で使用できるSalesforce Apexコーディング規約テンプレートを無料公開いたします。

本記事では、このテンプレートの特徴と効果的な活用方法について詳しく解説します。

是非、本テンプレートを利用して各プロジェクトの実態にあった実践的なApexコーディング規約を作成してみてください。

なぜApexコーディング規約が重要なのか

1. チーム開発における統一性の確保

複数の開発者が参加するプロジェクトでは、各々が異なるコーディングスタイルでコードを書いてしまうことがよくあります。

これにより、コードレビューが困難になり、バグの発見が遅れたり、新しいメンバーがコードを理解するのに時間がかかったりします。

統一されたコーディング規約があることで：

• コードの可読性が向上し、誰が書いたコードでも理解しやすくなる
• コードレビューの効率が上がり、品質向上に集中できる
• 新規参画メンバーのオンボーディングが迅速になる

2. Salesforce特有の制約への対応

SalesforceのApex開発では、一般的なプログラミング言語にはない独特の制約があります：

• ガバナ制限（SOQL、DML、CPUタイムなど）
• セキュリティモデル（共有設定、FLS）
• マルチテナント環境特有の考慮事項

これらの制約を理解せずに開発を進めると、本番環境で予期しないエラーが発生する可能性があります。

3. 保守性の確保

Salesforceシステムは長期間にわたって運用されることが多く、初期開発から数年後に機能追加や修正が必要になることが一般的です。この際、コーディング規約に従って書かれたコードは、修正や拡張が容易になります。

1.テーラリングガイド

目次サンプル

1.基本方針（可読性・保守性の重視）

テンプレートでは、「可読性の優先」「保守性の確保」「Salesforce固有の考慮事項」の3つを基本方針として掲げています。これらの方針は、長期的な開発・運用を見据えた重要な指針となります。

2.命名規則の統一

クラス名、メソッド名、変数名、定数名それぞれに対して明確なルールを設定しています。例えば：

クラス名: PascalCaseで名詞または名詞句を使用

• AccountService
• accService

メソッド名: camelCaseで動詞または動詞句で開始

• updateAccountStatus()
• update()

3.コード構造とフォーマット

一貫したインデント（4スペース）、適切な行の長さ（120文字以内）、効果的な空行の使用など、チーム全体で統一すべき基本的なフォーマットルールを定義しています。

4.クラス設計のベストプラクティス

クラス内の要素の配置順序（定数→静的変数→インスタンス変数→コンストラクタ→パブリックメソッド→プライベートメソッド）や、適切なアクセス修飾子の使用方法を明示しています。

5.SOQL/DML操作の最適化

Salesforce開発で最も重要な要素の一つであるデータベース操作について、パフォーマンスとガバナ制限を考慮したベストプラクティスを提供しています：

• バルク処理の実装方法
• 効率的なSOQLクエリの書き方
• Database クラスを使用した部分成功制御

6.包括的なテスト戦略

85%以上のテストカバレッジ達成を目標とし、ポジティブ・ネガティブ両方のテストケースを含む、実践的なテストクラス作成方法を解説しています。

テンプレートの効果的な活用方法

1. プロジェクト開始時の規約策定

新しいSalesforceプロジェクトを開始する際、このテンプレートをベースとして、プロジェクト固有の要件に合わせてカスタマイズすることで、短時間で実用的なコーディング規約を策定できます。

活用手順：

1. テンプレートをダウンロードし、開発チーム全体で内容を確認
2. プロジェクトの特性に応じて、必要な項目を追加・修正
3. チーム内での合意形成とドキュメント化
4. 開発環境への組み込み（IDE設定、CI/CDパイプライン）

2. 既存プロジェクトの品質改善

既に進行中のプロジェクトでも、段階的にコーディング規約を導入することで品質向上を図ることができます。

段階的導入のアプローチ：

• 第1段階: 新規開発コードから規約適用開始
• 第2段階: 既存コードの修正時に規約に合わせてリファクタリング
• 第3段階: 重要なモジュールから順次全面的な規約適用

3. コードレビューの効率化

テンプレートに含まれるチェックリストを活用することで、コードレビューの観点が明確になり、見落としを防ぐことができます。

チェックリストの活用例：

• 基本事項（命名規則、アクセス修飾子、フォーマット）
• 設計・構造（単一責任原則、メソッドサイズ、例外処理）
• Salesforce固有（ガバナ制限、バルク処理、セキュリティ）
• パフォーマンス（SOQLクエリ最適化、DML最適化）

4. 新人教育・オンボーディング

新しくチームに参加する開発者に対して、このテンプレートを教育資料として使用することで、Salesforce開発のベストプラクティスを効率的に伝えることができます。

実装時の注意点とコツ

段階的な導入を心がける

すべての規約を一度に導入しようとすると、開発チームに大きな負担をかけてしまいます。重要度の高い項目から順次導入し、チーム全体が慣れてから次の項目に進むことが重要です。

ツールを活用した自動化

可能な限り、IDE（Salesforce CLI、VS Code）の設定やCI/CDパイプラインを活用して、規約チェックを自動化しましょう。手動でのチェックに頼りすぎると、継続が困難になります。

定期的な見直しと改善

プロジェクトの進行に伴い、新たな課題や改善点が見つかることがあります。定期的に規約を見直し、チームの成長とプロジェクトの変化に応じてアップデートしていくことが大切です。

テンプレートに含まれる実践的なコード例

このテンプレートの大きな特徴の一つは、豊富な実装例が含まれていることです。抽象的な説明だけでなく、具体的なコード例を通じて「良い例」と「悪い例」を明示しているため、開発者が実際のコーディング時に迷うことなく適用できます。

バルク処理の実装例

//  良い例 - バルク処理対応
public void updateAccountTypes(List<Account> accounts, String newType) {
    List<Account> accountsToUpdate = new List<Account>();
    
    for (Account acc : accounts) {
        if (acc.Type != newType) {
            acc.Type = newType;
            accountsToUpdate.add(acc);
        }
    }
    
    if (!accountsToUpdate.isEmpty()) {
        try {
            Database.update(accountsToUpdate, false);
        } catch (DmlException e) {
            handleDmlException(e);
        }
    }
}

セキュリティを考慮した実装例

//  良い例 - 権限チェック
public void updateAccounts(List<Account> accounts) {
    if (!Schema.SObjectType.Account.isUpdateable()) {
        throw new SecurityException('Insufficient privileges to update Account');
    }
    
    update accounts;
}

継続的な品質向上のために

コーディング規約の導入は、ゴールではなくスタートラインです。継続的に品質を向上させるために、以下の取り組みを推奨します：

定期的なコードレビュー会の実施

チーム全体でコードレビューを行う時間を定期的に設け、規約の適用状況や新たな課題について議論します。

メトリクス測定と改善

テストカバレッジ、複雑度、規約違反数などのメトリクスを測定し、定量的な改善を図ります。

知識共有とベストプラクティスの蓄積

チーム内で発見されたベストプラクティスを規約に反映し、組織の知見として蓄積していきます。

まとめ

今回公開したSalesforce Apexコーディング規約テンプレートは、実際の開発現場での経験を基に作成された実践的なドキュメントです。このテンプレートを活用することで、開発チームは以下のメリットを得ることができます：

• 開発効率の向上: 統一されたコーディングスタイルにより、コードレビューや保守作業が効率化
• 品質の向上: Salesforce特有の制約を考慮したベストプラクティスにより、バグの削減と性能向上を実現
• チーム力の強化: 共通の規約により、チーム内でのコミュニケーションと協力が促進
• スケーラビリティの確保: 将来の機能拡張や保守作業に対応しやすいコード構造の実現

Salesforce開発の品質向上を目指すすべてのチームに、このテンプレートを積極的に活用していただき、より良いシステム開発を実現していただければと思います。

資料のダウンロード

テンプレートのダウンロードは、Creative Content Lab Tokyoの公式サイトから無料で行えます。ぜひ、あなたのプロジェクトでもご活用ください。

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

開発コーディング規約のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

最後に

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

突然ですが、皆さんはSalesforce workbench（ワークベンチ）を使ったことがありますか？

Salesforceの開発に携わった方は、開発者コンソールを使うことは多いと思いますが、リリースや運用保守でメタデータのバックアップを行うなどの機会がない方は使ったことがないという場合も多いと思います。

Workbenchには様々な機能があり、管理者や開発者にとっては開発者コンソール同様、非常に便利なツールとなります。

ワークベンチはWebブラウザから簡単にアクセスすることができ、Salesforce組織ともAPIで簡単に接続できます。さらにブラウザ上から直接クエリを発行したり、メタデータを取得（Retrieve）したり、デプロイ（Deploy）することもできます。

※Bulk、Rest ストリーミング、メタデータなどもサポートしています。

またよく利用されるパターンとして、本番環境で不要となったプログラムを削除するような場合にも利用されています。

1 Workbench概要

1-1. Workbenchとは

Salesforce Workbenchは、Salesforceプラットフォームのメタデータ管理やApexコードの実行、Salesforce APIを使ったデータへのアクセスなどを行う機能が提供されたWebベースのツール（サービス）です。

Workbench（ワークベンチ）を使うことで、システム管理者や開発者はプログラムコードを書くことなく、Webブラウザ上からの操作で簡単にメタデータを取得したり、APIを実行したりすることができます。

公式サイトのURLはこちら「Workbenchサイト（https://workbench.developerforce.com/login.php）」

1-2. 機能一覧

ワークベンチ（workbench）が現時点で提供している機能は以下の通りです。

以上のように、非常に実用性の高い機能が用意されています。

2.Workbenchの使い方

2-１． Workbenchへの接続方法

手順①Workbenchへログインするために以下の公式サイトへブラウザでアクセスします。

Workbenchサイト（https://workbench.developerforce.com/login.php）

• Environment（接続環境）を選択：Production（本番）、またはSandboxを選択します。
• API Version：利用したいAPIのバージョンを指定します。　※バージョンによって利用可能な機能が異なりるため注意

手順②「I agree to terms of service」にチェックを入れて、Login with Salesforceのボタンをクリックします。

手順③Salesforce組織にログインするためのユーザ名とパスワードを入力してログインを行います。

※すでにSalesforce組織にログインしているブラウザでWorkbenchを実行している場合は自動的に接続されます。

手順④Salesforce組織に接続後は、以下ワークベンチのメニューが表示されます。

各機能の利用方法は次の章で紹介します。

3. 機能紹介

3-1. メタデータ照会機能

①Standard ＆Custom Objects（標準＆カスタムオブジェクト）

指定したオブジェクトに関するメタデータ情報を参照することができます。※以下はユーザオブジェクトを照会した例

照会できる情報は以下の通り

• 属性
• 子リレーション
• フィールド（項目）
• レイアウト名

②Metadata Types & Components（メタデータタイプ＆コンポーネント）

メタデータタイプの確認やコンポーネントについての詳細情報（ID、名称、作成者/作成日、最終更新者/最終更新日など）の情報を確認することができます。

上記は、フローのメターデータを照会した例

③Session Information（セッション情報）

接続しているSalesforceインスタンスのセッション情報（サービスのエンドポイントなど）を確認することができます。

取得可能な情報

• APIのバージョン
• クライアントID
• エンドポイント

（ユーザ情報）

• プロファイル
• ロール
• ユーザ名
• ユーザID
• タイムゾーン、ユーザタイプなど

（組織）

• 添付ファイルの上限など

3-2. クエリ実行機能

①SOQL Query（SOQLクエリ実行）

SOQLを直接実行することができます。表示形式やソート順の指定が可能またフィルタ条件や取得レコードの上限の指定も可能です。そのほか、削除済み、アーカイブレコードを含めるかなどの指定もできます。

SOQL実行結果

②Async SOQL Query

非同期のSOQL(Insert/Upsert）の実行ができます。

③SOSL Search

SOSL（Salesforce Object Search Language) の実行が可能です。※Salesforceのレコード内のテキスト検索を実行

SOSLの実行結果（CCLTという文字列での検索を実行）

④Streaming Push Topics

本機能は、Salesforceのレコードを監視し、本機能で登録したSOQLクエリに該当した場合に、あらかじめ購読（Subscribe登録）されたクライアントに対して、プッシュ通知を実現するものとなります。

以下のメッセージが表示される場合は、Salesforce組織のストリーミングAPIの有効化がされていないため、先に設定しておく必要があります。また本機能を使う場合には、事前にSalesforce側でプッシュ通知の各種設定が必要となります。

PushTopicに関しては、少し古いですが、テラスカイさんの以下の記事がわかりやすいかと思います。

3-３. データ操作（DML）機能

①Insert

指定オブジェクトに対して1つまたは複数のレコードを登録することができます。

以下の画面で登録するための項目の値を指定して実行

実行結果を表示（成功すると以下のように表示されます）

②Update

指定オブジェクトに対して1つまたは複数のレコードを更新することができます。

以下の画面で更新レコードのIDを指定して、変更後の値をセットしたら実行

実行結果の画面

③Upsert

指定オブジェクトに対して1つまたは複数のレコードを登録＆更新することができます。

更新の場合はIDを指定して、変更後の値をセットして実行（新規の場合はID指定なし）

実行結果

④Delete

指定オブジェクトに対して1つまたは複数のレコードを（ごみ箱に）削除することができます。

削除対象レコードのIDを指定して実行

実行結果

⑤Undelete

指定オブジェクトに対して1つまたは複数の削除されたレコードを復元することができます。

UndeleteしたいレコードのIDを指定して実行

Undeleteの実行結果

⑥Purge

指定オブジェクトに対して1つまたは複数の削除されたレコードをごみ箱から完全に削除することができます。

Purgeしたいレコードを指定して実行

Purge（パージ）の実行結果

3-４. マイグレーション機能

①Retrieve（取得）

指定されたマニフェストファイル（Package.xml）に定義されたメタデータをdownloadすることができます。

Package.xmlファイルを指定します。

全てのメタデータ取得用のファイルが欲しい方は、以下からダウンロードしてご利用いただけます。

参考

全メタデータ取得用のマニフェストファイル（Package.xml）のサンプルダウンロード

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

Retriveを実行した結果

上記のDownload ZIP Fileをクリックするとメタデータのファイルをダウンロードすることができます。

ダウンロードしたメタデータはデプロイして元に戻すことができます。

②Deploy（デプロイ）

指定されたメタデータをSalesforce組織にデプロイすることができます。

オプションで、チェックだけを行う、ワーニングを無視、テストレベルやテストの実行指定などができます。

あらかじめ取得しておいたメタデータファイル（ZIP形式）を指定して実行します。

実行中の画面

実行結果の確認画面

3-５. その他ユーティリティ

①Rest Explorer

WorkbenchからSalesforce組織に対して直接REST APIを実行することができます。

利用可能なメソッドは、GET、POST、PUT、PATCH、DELETE、HEADとなります。

②Apex Execute

Apexコードを直接実行することができます。※開発コンソールと同様

実行すると以下のようなデバッグログが表示されます。

③Password Management（パスワード管理）

ユーザのパスワードを設定したりリセットすることができます。

パスワードを設定/変更したいユーザIDと新しいパスワードを指定してChange Passwordを実行します。

④Bulk API Job Status

DataloaderやWorkbenchなどから実行されたBulk APIのジョブステータスを確認することができます。

一括データ読み込みジョブのIDを指定して実行

ジョブの実行状況（結果）が表示されます。

⑤Metadata API Process Status

メタデータAPIの処理プロセスのステータス（実行状況）を確認することができます。

確認したいIDを指定して実行します。

Salesforce workbenchの概要説明資料のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

参考

要件定義_ユーザ説明資料_Salesforce Workbench（ワークベンチ）機能概要説明」ダウンロード

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

まとめ

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

【重要】設計・開発時のレビュー関連（アンチパターン）

権限設計

①組織の共有設定、共有ルールを利用する前提で権限設定を行う場合、1オブジェクト当たり最大で300までの共有ルールしか設定できないことに注意が必要

サポートへ依頼することで、最大500まで拡張することは可能（エンティティごとの共有ルールの最大数の拡張）

公式のヘルプサイト：https://help.salesforce.com/s/articleView?id=000384485&type=1

ただし、共有ルールを大量に用いる場合は処理性能に影響が出る可能性が高いため性能要件も合わせて確認が必要

もし1オブジェクトあたり500以上のグループやユーザに対して共有ルールを設定する必要があるという場合でも拡張はできないため、個別に権限付与のSObjectのShareオブジェクトに対してレコードを生成するようなトリガーなどの処理を開発して対応が必要となります。

要件定義の段階で、必用な権限グループの総数は確認するようにしておきましょう。

データモデルの設計

①主従関係構築する際、1つの親レコードに対して、最大何件の子レコードが関連するか。

10万件を超過することが予想される、且つ、親レコードは削除処理の対象となることがある場合には、参照関係に変更できないか検討する。

※参照関係でも、カスケードオプションは付けないようにする必要がある！！

積み上げ集計などが必要な場合はトリガーやバッチ処理で代替することを検討したほうがよいです。

例えば、バッチ処理で、主従関係の子レコードを10万件以上削除したあとに、親レコードを削除しようとすると以下のようなエラーが発生します。

「Delete failed. First exception on row 0 with id a035h00000TE1BGXXX; first error: DELETE_OPERATION_TOO_LARGE, Cascade deleting too many records: occurring when cascading to」

カスケード削除（親と一緒に関連する子レコードなどを削除する）の場合に、削除対象のレコード数が多すぎて削除できない制約

Salesforceではカスケード削除は10万件までの上限でハードコーディングされているようで変更不可とのこと。

子レコード削除後は、ごみ箱に入って、完全に物理削除されるまで通常何日か必要です。その間は親レコードが削除できなくなるため、バッチ処理などで親子セットで削除すると親だけ最後に削除できず上記エラーが発生します。

ApexTrigger（トリガ）の設計・開発

Apexバッチの設計・開発

Startメソッドの中で、QueryLocatorの代わりにAggregateResultのIteratorなどを使っていないか。データが少量の場合は、成功するが大量の場合は、queryMore()が発生して以下のエラーが発生するので要注意！

「Aggregate query does not support queryMore(), use LIMIT to restrict the results to a single batch」

対方針：集計が必要な処理はSOQLの集計関数ではなく、For文などの繰り返し処理で計算させること。

フローの設計・開発

【画面処理フロー】

フローでは、要素の割り当てのガバナ制限があります。繰り返し処理で変数の割り当て処理が多い場合、以下のエラーが発生する可能性があります。

「お客様の組織はこの機能に対する最大限度を超えました。」

（対処方法）

上記エラーが出る場合は、要素の割り当て数を少なくするしかないため、大量データの加工などが必要な処理はフローではなく、トリガーまたは画面の開発を行う必要があります。

フローのテキストコンポーネントに入力された値を使って、すでに登録済みのデータと重複チェックをする場合、テキスト前後の半角/全角SP（スペース）やタブをTrimしない状態で重複チェックをすると、SOQLでの検索では、スペースなどが含まれた状態で検索されるため重複とならないが、レコードを登録する（INSERT･UPSERTなど）の際には、自動的にトリムされるため重複エラー（DML Exception）が発生します。

例えば取引先番号”ACC123″のレコードが取引先に存在する場合に、画面で入力された”　A123　”をSOQLで検索すると別の文字列のためレコードは検索されず重複なしと判断できます。

ただし、INSERT時には、Salesforceでは自動的に前後がトリムされるため”ACC123″としてレコードを登録しようとして重複エラーが発生します。

重複チェックをする項目については、上記が考慮された設計となっているかチェックする必要があります。

モバイルアプリケーションを利用する場合

・動的関連リスト（Summer22）を利用している場合、モバイルでは対応していないためタブが表示されなくなる（2022/7/7月時点の情報）

→（対策）標準の関連リストを利用もしくは、List Editorの利用　（こちらの記事を参考）

・Lightning web componentで開発した機能を呼び出すアクションを利用する場合、モバイルでは対応していない（2022/7/7月時点の情報）

→（対策）こちらについては、Aura Componentでアクションボタンを作成して、ラップすることで回避可能

上記のほかモバイルの考慮事項は、公式サイトで最新状況を確認してください。

また、Apexのサンプルコードとして提供している「取引先責任者を使って、カスタマーポータルユーザを作成」を利用して、取引先責任者のカスタマーポータルユーザを作成して、カスタマーポータルサイトにログインするまでの手順を説明してみたいと思います。

※Apexの開発は難しいという方は、標準の機能を使って取引先責任者からポータルユーザを使ってログインしてください。

【必要なライセンス】

カスタマー取引先ポータル（カスタマーポータル）を利用するためには、カスタマーポータルユーザライセンス（※１）が必要となります。

※Experience Cloudユーザライセンス（外部ユーザラインセンスとして、Customer Community、Customer Community Plusのいずれか）

代理店などの自社パートナーに対しては、別のパートナーコミュニティラインセンス（Partner Community）が用意されているので注意

サポーターさん

Developer Edition環境を使えば動作検証は可能です

Developer Edition（無料の開発環境）を持っていない方は、以下の記事を参考にSalesforce組織を取得してください。

参考

セールスフォースの基礎Ⅰ（３）Developer組織の作成～ログインまで

【第三回】セールスフォースの基礎講義 前回の記事では、インスタンスとリージョンの…

続きを読む

デジタルエクスペリエンス（Experience Cloud サイト）について

デジタルエクスペリエンス（Experience Cloud サイト ※旧Community Cloudサイト ）：Salesforce CMS、Mobile Publisher、Web アプリケーションスイートが結合されてた堅牢なカスタマイズされたサイト

簡単に言うと、Salesforce CRMと連携して、従業員/顧客/パートナー（代理店など）向けの公開ポータルサイトを非常に簡単に作成することができる機能（サービス）となります。

Salesforce内の各種データを共有（公開）したり、Salesforceの標準機能を外部向けに利用可能とすることができます。

サポーターさん

顧客向けにナレッジ（よくある質問やお問い合わせ）などの情報を公開することで、サポートコストを低減するなども目的で利用したり、だ代理店などのパートナー向けに商談などの情報を公開するような利用方法もあります。

サイトの構築は非常に簡単で、ノンコーディングで作成することもできますし、開発したコンポーネントなどを配置して利用することもできます。

さらに、各種CMSのテンプレートが提供されていて、テンプレートを適用するとおしゃれなページが簡単に構築できます。

※以下、選択可能なテンプレート（一部）

Experience Cloudユーザライセンスの種類

Experience Cloudユーザライセンス（旧Community Cloud）は、以下の種類があります。（2022/06/11時点）

以下、【引用元】：Salesforce公式HELPサイト「Experience Cloud ユーザライセンス」

上記の通り、ポータル系のライセンス体系は用途によって、細分化されているのでお客様の要件によって適切なものを選択する必要があります。

今回の記事で利用するのは、「Customer Community（カスタマーコミュニティ）」ライセンスとなります。

取引先責任者をカスタマーポータルユーザとして、新規ユーザを作成するため、Customer Communityが必要となります。

代理店などのパートナー向けにユーザを作成する場合には、Partner Communityのライセンスが必要となります。

ライセンス毎の課金体系について

デジタルエクスペリエンスのポータルサイトでは、大きく2種類のライセンス課金体系があります。

１．メンバーベースライセンス

ユーザに紐づくライセンス体系で先ほどご紹介したライセンス体系（Customer Community、Customer Community Plus、Partner Community、外部アプリケーション、Channel Account）がそれに該当します。

メンバーベースライセンスの場合、ユーザが月に何度ログインしても料金体系は変わらず固定となります。（ひと月当たりいくら）

２．ログインベースライセンス

ログインベースライセンスのライセンス体系は（Customer Community Login、CustomerCommunity Plus ログイン、Partner Community ログイン、External Apps Login、Channel Account Login）となっており、各種メンバーライセンスにログインが付いたライセンス名となっています。

ログインベースのライセンスの場合、毎月利用する特定数のログイン(※1)を購入することになります。

※1.ライセンスに関連付けられている外部ユーザは、サイトにログインする度に1 ログインを消費します。

ただし、同一ユーザが同じ日に複数回ログインしても、消費するのは 1ログインというカウントとなります。（日次ユニークログインと呼ばれる）

ポータルサイトの目的やユーザの利用状況によって、最適なライセンスを選択する必要があります。

デジタルエクスペリエンスでカスタマー取引先ポータルを作成

ここからは実際にSalesforceの組織にログインして、カスタマポータルのサイトを作成していきたいと思います。

1.デジタルエクスペリエンスの有効化

まず最初にデジタルエクスペリエンスの機能を有効化します。

手順①システム管理者でログイン後、[設定]->[デジタルエクスペリエンス]->[設定]の順に実行します。

以下の画面が表示されたら、デジタルエクスペリエンスを有効化にチェックします。

手順②デジタルエクスペリエンスを有効化にチェックすると、ドメイン名の選択項目が表示されます。

ドメイン名に作成したいドメイン名を入力して、[参加可能か調べる]をクリックして、ドメインが利用可能かチェックします。

手順③ドメイン名のチェックが終わったら、保存ボタンをクリックします。

すると以下の警告メッセージが表示されるので、問題なければOKをクリックして有効化を完了します。

「デジタルエクスペリエンスを有効化すると、レコードアクセス権が「ロール＆下位ロール」から「ロール、内部＆ポータル下位ロール」に自動的に変更されます。ポータル下位ロールにアクセス権を開放すると、組織のデータが外部ユーザに公開される可能性があります。デジタルエクスペリエンスを有効化したら、[デジタルエクスペリエンス] > [サイトメンバーアクセス権の変換] ツールを実行してデータアクセス権を保護してください。

デジタルエクスペリエンスを有効化したら、ドメイン名の変更やデジタルエクスペリエンスの無効化ができなくなります。

手順④有効化を実施後、以下の通り、成功しましたのメッセージが表示されれば有効化作業が完了となります。

2.カスタマーコミュニティユーザ用プロファイルの作成

カスタマーコミュニティ用のプロファイルを作成します。

※サイト公開前にはプロファイルを含め、必要なセキュリティ設定は必ず済ませておいてください

手順①システム管理者で、[設定]->[ユーザ]->[プロファイル]の順に実行します。

プロファイル一覧から、[Customer Community User]プロファイルの横にあるコピーリンクをクリックします。

手順②プロファイルのコピー画面で、カスタムプロファイルの名前を指定して保存ボタンをクリックします。

例では、「Custom Customer Community User」という名前にしています。

※Apexのコードサンプルではこの名称を利用してプロファイルを取得しています。名前を変更する場合、Apexコードで指定しているプロファイル名も変更してください

プロファイル作成後は、必ずプロファイルに設定されている権限の確認をしてください。（必要ない権限は削除）

3.新規カスタマー取引先ポータル（サイト）の作成

手順①デジタルエクスペリエンスを有効化すると、デジタルエクスペリエンスメニューに、すべてのサイトが表示されるので、クリックして実行します。

すべてのサイトページで、[新規]ボタンをクリックして、新規サイトの作成を行います。

手順②新規ボタンをクリックすると、お気に入りのエクスペリエンスの選択画面が表示されます。

ポータルの利用用途に沿った各種テンプレートが用意されています。

手順③今回は、カスタマー取引先ポータルを選択します。

手順④カスタマー取引先ポータルの画面で内容を確認したら、「使用を開始する」ボタンをクリックします。

手順⑤続いて、ポータルの名前を設定後、作成ボタンをクリックします。　※サイトのページのURLは省略可能。

手順⑥サイトの作成処理が開始されます。

手順⑦サイトの作成が終わると以下のワークスペースの画面が表示されます。

手順⑧ワークスペースからビルダーのメニューを実行します。

すると以下のようなホーム画面が表示されます。

4.カスタマー取引先ポータルサイトのカスタマイズ

まずは、サイトへアクセス可能なプロファイルを設定します。

手順①サイト作成後、ビルダーの左上のメニューから「管理」メニューを実行します。

手順②管理メニューの中から、メンバーメニューをクリックします。

選択可能なプロファイルで、作成したプロファイル「Custom Customer Community User」を選択して選択済みへ追加します

続いては、新規作成したカスタマー取引先ポータルサイトのレイアウトなどのカスタマイズを行います。（ここは省略してもよいです）

ポータル画面の設定やカスタマイズに関しては、別の記事で詳細をご説明したいと思います。

今回は、以下のようにダッシュボードのコンポーネント追加と、ケースの一覧表示だけ追加しています。

手順①カスタマイズが終わったら、画面右上の公開ボタンをクリックしてページを公開します。

5.取引先、取引先責任者レコードの作成

続いては、取引先と取引先責任者のレコードを作成していきます。

※ここはSalesforceの基本的な操作となるため、詳細な手順は省略します。

【例】以下の取引先と取引先責任者を作成

取引先責任者については、取引先は上記で作成した取引先に紐づけて作成

姓名とメールアドレスは必ず設定するようにしてください。　※メールアドレスは新規ポータルユーザを作成するときに利用します。

6.取引先責任者のカスタマーコミュニティユーザを作成

続いては、作成した取引先責任者をカスタマーポータルユーザとして有効化します。

その１（標準機能を使ったやり方）

手順①取引先責任者のページレイアウトを編集して、モバイルおよびLightning アクションから、「カスタマーユーザを有効化」「カスタマーユーザを無効化」「カスタマーユーザを表示」のボタンをレイアウトに配置して保存します。

手順②取引先責任者の詳細画面で「カスタマーユーザを有効化」ボタンをクリックします。

手順③ユーザの新規作成画面に遷移するので、この画面でライセンスとプロファイルを以下に変更して保存します。

・ユーザライセンス：Customer Community

・プロファイル：Custom Customer Community User

そのほか、ユーザ名など変更したい箇所があれば編集してから保存します。

手順④作成時に以下の警告メッセージが表示されます。問題なければOKをクリックします。

任意のコミュニティで [お知らせメールを送信] オプションを選択している場合、そのコミュニティの新規メンバーはお知らせメールメッセージを受信します。このコミュニティメンバーにお知らせメールメッセージを送信しない場合は、[お知らせメールを送信] オプションを選択解除します。

手順⑤ユーザ作成後に以下のメールが届きます。メール内のリンクをクリックします。

手順⑥パスワードの設定画面にて新規パスワードを設定します。設定後パスワードの変更を実行

7.カスタマーコミュニティユーザでカスタマー取引先ポータルサイトへログイン

パスワードの変更を行うと自動的にログインされます。作成したサイトのログイン画面が表示されれば成功となります。

カスタマーポータルユーザの作成（ApexTriggerサンプルコード）

今回は、取引先責任者の標準機能「カスタマーユーザを有効化」機能を使ってユーザを作成しましたが、フローアクションやApexなどで自動的にユーザを作成したい場合もあると思います。

取引先責任者IDを使って、Apexで自動的にカスタマーユーザを作成する方法については、以下にサンプルコードを用意しています。

ユーザ作成後は、ユーザ宛にメールが届きます。※メール内リンクからユーザを有効化＆パスワードの変更を実施してログイン可能となります。

参考

カスタマーポータルユーザの作成（Apex Class サンプルコード）

今回のサンプルは、取引先責任者IDを使ってカスタマー取引先ポータルのユーザを作成…

続きを読む

まとめ

今回は、カスタマーポータルを作成してポータルユーザでログインする手順についてご説明しました。

デジタルエクスペリエンスの構築方法では、開発機能を使ったサイト作成なども実際のプロジェクトでは多いと思いますので、別の機会に開発機能を使ってのサイト作成方法をご紹介したいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

第三回の今回は、CircleCI を DevHub に接続から最後のCircleci での自動ビルドまでの設定して、動かしてみましょう。

前回の記事はこちら

参考

CircleCIを使った継続的インテグレーション（Continuous Integration）第2回

第一回では、GuthubのセットアップからCircleCIのセットアップ、そして…

続きを読む

CircleCI を DevHub に接続

CircleCI を認証して接続アプリケーション経由でコンテンツを Dev Hub に転送できるようにします。

手順①コマンドプロンプトを起動し、server.key ファイルがあるフォルダから JWT ベース認証を実行できることを確認します。

以下のコマンドを実行

</p>
<p>>sfdx auth:jwt:grant –clientid <your_consumer_key> –jwtkeyfile server.key –username <your_username> –setdefaultdevhubusername</p>
<p>

【実行例】

</p>
<p>>sfdx auth:jwt:grant –clientid 3MVG95mg0lk4batiP7Q5f8gZVROjIpEdZT… –jwtkeyfile server.key –username cclt.sfdc@mail.com –setdefaultdevhubusername</p>
<p>

以下のようなメッセージが表示されれば認証成功です。

Successfully authorized<ユーザ名> with org ID 00D5h000004bs…

ローカルにsfdx-circleci リポジトリをフォーク

手順①ブラウザで以下のURLへアクセスしsfdx-circleci のリポジトリを表示します。

手順②GitHubを開いたら画面右上の【Fork（フォーク）】リンクをクリックします。

手順③GitHubのログイン画面が表示される場合は、IDとパスワードを入力してログインします。

手順④Create forkを実行して、sfdx-circleciリポジトリをコピーします。

手順⑤フォークが完了すると自分のGitHubに以下の内容が表示されます。

手順⑥次にCircleCIにログインして、プロジェクトメニューを表示します。

すると先ほどフォークしたsfdx-circleciのリポジトリが表示されているので、リポジトリ名のリンクをクリックします。

手順⑦config.ymlファイル選択画面が表示されます。sfdx-circleciに用意されているconfig.ymlをそのまま利用してSet up Projectを実行します。

手順⑧新規プロジェクトが作成されPipelineが実行されます。

手順⑨初回（環境設定を行っていない状態）では、実行結果がFailedとなります。

ビルドにエラーの原因が表示されます。※環境設定などを実施しない限り必ずエラーとなります。

手順⑩続いて環境設定を行います。実行結果の右側に表示されている・・・ボタンをクリックして、プロジェクト設定（Project Settings）メニューを表示します。

手順⑪プロジェクト設定画面で環境変数の設定（Environment Variables）メニューを実行します。

手順⑫以下の環境変数設定画面で、Add Environment Variableをクリックします。

手順⑬環境変数の登録画面で、以下4つのパラメータを指定します。

【登録する環境変数と値】

1. [HUB_CONSUMER_KEY]：作成したSFDCの接続アプリケーション画面で生成されたコンシューマ鍵を指定します。
2. [HUB_SFDC_USER]：組織に接続するユーザ名を指定します。
3. [DECRYPTION_KEY]：server.keyファイルの暗号化の際に生成したkeyを指定します。
4. [DECRYPTION_IV]：server.keyファイルの暗号化の際に生成したivを指定します。

※2番目のパラメータについて、Salesforceの説明サイトでは、HUB_SFDX_USERとなっていますが、sfdx-circleciから取得したconfig.ymlを確認すると正しくは、$HUB_SFDC_UESRとなっているので、間違えないように注意してください。

手順⑭続いて、server.key.encファイルを更新します。

コマンドプロンプトを起動して以下のコマンドを実行します。sfdx-circleciリポジトリをローカル環境へクローンします。

</p>
<p>> cd C:\Users\e\dev\jdoe\JWT   ※JWTフォルダへ移動（※Git専用のフォルダがあればそちらへ移動してもよいです）</p>
<p>>git clone https://github.com/<GitHubのユーザ名>/sfdx-circleci.git<br />
Cloning into ‘sfdx-circleci’…<br />
remote: Enumerating objects: 90, done.<br />
remote: Counting objects: 100% (24/24), done.<br />
remote: Compressing objects: 100% (21/21), done.<br />
remote: Total 90 (delta 9), reused 2 (delta 0), pack-reused 66<br />
Receiving objects: 100% (90/90), 357.09 KiB | 13.73 MiB/s, done.<br />
Resolving deltas: 100% (28/28), done.</p>
<p>

手順⑮ローカルのgitへクローンが作成されたら..\sfdx-circleci\assets\配下にエンコードした[server.key.enc]ファイルをコピーします。

</p>
<p>>copy server.key.enc sfdx-circleci\assets\</p>
<p>

手順⑯リポジトリを作成したら次はgit addコマンドでファイルをインデックスに追加します。

</p>
<p>>cd sfdx-circleci\assets\</p>
<p>>git add server.key.enc</p>
<p>

手順⑰追加されたかステータスを確認

</p>
<p>>git status</p>
<p>On branch master<br />
Your branch is up to date with ‘origin/master’.</p>
<p>Changes to be committed:<br />
(use “git restore –staged <file>…” to unstage)<br />
new file: server.key.enc</p>
<p>

手順⑱追加されていることを確認したらコミットします

</p>
<p>>git commit -m “update server.key.end” -v</p>
<p>[master 827e48b] update server.key.end<br />
1 file changed, 37 insertions(+)<br />
create mode 100644 assets/server.key.enc</p>
<p>

手順⑲最後にgitにプッシュします。

</p>
<p>>git push</p>
<p>info: please complete authentication in your browser…<br />
Enumerating objects: 6, done.<br />
Counting objects: 100% (6/6), done.<br />
Delta compression using up to 8 threads<br />
Compressing objects: 100% (4/4), done.<br />
Writing objects: 100% (4/4), 2.13 KiB | 2.13 MiB/s, done.<br />
Total 4 (delta 1), reused 0 (delta 0), pack-reused 0<br />
remote: Resolving deltas: 100% (1/1), completed with 1 local object.<br />
To https://github.com/creativecontentlabtokyo/sfdx-circleci.git<br />
94c267b..827e48b master -> master</p>
<p>

※GitHubへのログイン認証が必要な場合はIDとパスワードを入力します。最後にリポジトリにserver.key.encファイルが登録されていることを確認します。

手順⑳CircleCIの画面に戻り、プロジェクト[sfdx-circleci]のConfigurationを実行します。

手順㉑config.ymlについて、以下2点の修正を行いSave＆Runを実行します。

1. –setdefaultdevhubusername -a hub　⇒　今回は[my-hub-org]というエイリアスを使っていたのでこちらに修正します。
2. force:org:createの　–waitはデフォルト2ですが、3にしたほうがよいと記載があったので3に修正します。

</p>
<p>sfdx force:auth:jwt:grant –clientid $HUB_CONSUMER_KEY –jwtkeyfile assets/server.key –username $HUB_SFDC_USER –setdefaultdevhubusername -a <span style="color: #ff0000;">my-hub-org</span><br />
sfdx force –help<br />
sfdx force:org:create -s -f ~/ci_app/config/project-scratch-def.json -a circle_build_$CIRCLE_BUILD_NUM –wait <span style="color: #0000ff;">3</span></p>
<p>

手順㉒CircleCIの画面に戻って、再実行されたWorkflowの結果を確認しましょう

以下のSetup Orgの箇所で、Successfully Authorized ord ID ….と表示されていれば組織認証までは成功しています。

手順㉓Setup Orgで以下のエラーが発生していたので修正していきます。

</p>
<p><span style="color: #ff0000;">WARNING: Warning: If you’re using Contacts to Multiple Accounts, beginning with the Spring ’21 release, the feature isn’t automatically enabled. You must manually enable the setting for new scratch orgs. Enable the setting in one of these ways: update the Account Settings page in Setup, add the enableRelateContactsToMultipleAccounts setting to your scratch org definition file, or enable it via Metadata API.</span></p>
<p>ERROR running force:org:create: We’ve deprecated OrgPreferences. Update the scratch org definition file to replace OrgPreferences with their corresponding settings.</p>
<p><span style="color: #ff6600;">Replace the orgPreferences section:</span><br />
<span style="color: #ff6600;">{</span><br />
<span style="color: #ff6600;">“orgPreferences”: {</span><br />
<span style="color: #ff6600;">“enabled”: [</span><br />
<span style="color: #ff6600;">“S1DesktopEnabled”</span><br />
<span style="color: #ff6600;">]</span><br />
<span style="color: #ff6600;">}</span><br />
<span style="color: #ff6600;">}</span><br />
<span style="color: #ff6600;">With their updated settings:</span><br />
<span style="color: #ff6600;">{</span><br />
<span style="color: #ff6600;">“settings”: {</span><br />
<span style="color: #ff6600;">“lightningExperienceSettings”: {</span><br />
<span style="color: #ff6600;">“enableS1DesktopEnabled”: true</span><br />
<span style="color: #ff6600;">}</span><br />
<span style="color: #ff6600;">}</span><br />
<span style="color: #ff6600;">}</span><br />
For more info on configuring settings in a scratch org definition file see: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs.htm.’</p>
<p>Exited with code exit status 1<br />
CircleCI received exit code 1</p>
<p>

手順㉓GitHubの[project-scratch-def.json]ファイルを以下のように修正します。

ファイルパス：sfdx-circleci/config/project-scratch-def.json

</p>
<p><span style="color: #ff6600;">{</span><br />
<span style="color: #ff6600;">“orgName”: “Sample Org”,</span><br />
<span style="color: #ff6600;">“edition”: “developer”,</span><br />
<span style="color: #ff6600;">“settings”: {</span><br />
<span style="color: #ff6600;">“lightningExperienceSettings”: {</span><br />
<span style="color: #ff6600;">“enableS1DesktopEnabled”: true</span><br />
<span style="color: #ff6600;">}</span><br />
<span style="color: #ff6600;">}</span><br />
<span style="color: #ff6600;">}</span></p>
<p>

手順㉔最後にもう一度CircleCIの画面からsfdx-circleciプロジェクトのworkflowを再実行してみます。

Run Apex Tests

Setup Org

Uploading test results / Delete Useless Scratch Org

Parallel runs

全てSign up envirnmentから最後まですべて正常終了しました。

まとめ

今回の記事では、sfdx（CLI） と CircleCI を使って CI環境を作る手順について記しました。

GitHubの使い方やCircleCIなどのCI/DIツールについての基本知識がないと難しく感じる内容だったと思います。これを気に関係するツールや機能について学習することをお勧めします。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

第二回の今回は、Salesforceの組織とCircleCI間の認証に関する設定をしていきます。

前回の記事はこちら

参考

CircleCIを使った継続的インテグレーション（Continuous Integration）第1回

Salesforceの大型プロジェクトやアジャイル開発方式を採用したプロジェクト…

続きを読む

Dev Hub組織に対してJWTベースフローを使用した組織の認証を実行

Dev Hub組織に対してJWTベースフローを使用した組織の認証を実行します。※CircleCIからSalesforce組織に対する認証の設定

継続的インテグレーション（CI）の環境は自動化されており、OAuth2.0Webサーバ認証フローのユーザインタラクションはサポートされていないため、代替手段としてJWT（Json Web トークン）ベアラーフローを使用して組織を認証する必要があります。

非公開鍵と自己署名デジタル証明書の作成

OAuth 2.0 JWT ベアラー認証フローでは、証明書の署名に使用されるデジタル証明書と非公開鍵が必要になります。デジタル証明書をカスタム接続アプリケーションにアップロードします。このカスタム接続アプリケーションも JWT ベアラー認証フローで必要になります。認証機関で発行された独自の非公開鍵と証明書を使用できます。または、OpenSSL を使用して鍵と自己署名デジタル証明書を作成することもできます。

【Open SSLをインストール（未インストールの場合）】

手順①以下のサイトにWindows用にビルドされたインストーラがあるので、ダウンロードします。

Webサイト「Shining Light Productions（Win32/Win64 OpenSSL）」　※実行時点の最新版で構いません。

今回は、Win64 OpenSSL v1.1.1oのMSIをダウンロードします。

※Win64 OpenSSL v3.0.3の場合、最後のsfdxでの認証でエラーになることがわかっているので間違えないようにしてください。Issue（https://developer.salesforce.com/forums?id=9062I000000BmNHQA0）

ERROR running auth:jwt:grant: We encountered a JSON web token error, which is likely not an issue with Salesforce CLI. Here’s the error: error:25078067:DSO support routines:win32_load:could not load the shared library

Windows以外の場合は、Opensslのサイトよりダウンロードしてください。

「openssl.org：https://www.openssl.org/」

手順②ダウンロードしたインストーラ（MSIファイル）を実行します。

以下の警告メッセージが表示されるので、詳細情報のリンクをクリックします。

手順③実行ボタンが表示されるためクリックしてインストールを実行します。

手順④インストーラが起動されます。同意にチェックをして次に進みます。

手順⑤Opensslのインストール先フォルダを選択します。※デフォルトのままで大丈夫です。

手順⑥ショートカット名を指定します。※デフォルトのままで大丈夫です。

手順⑦OpenSSL DLLについては、二つ目のオプション（OpenSSL binaries(/bin)directory）を選択してください。

手順⑧最終確認後、Installボタンをクリックします。

手順⑨最後に寄付の画面が表示されますが、チェックを外してそのまま終了します。※寄付したい場合は任意のオプションを選択

手順⑩続いて、インストールしたOpensslのパスを設定します。システムのプロパティから詳細設定を開きます。環境変数のボタンをクリックします。

手順⑪環境変数の画面にて、ユーザ環境変数の編集ボタンをクリックします。

手順⑫新規ボタンをクリックして、Opensslをインストールしたフォルダのフルパスを登録します。

手順⑬以下のように新規パスが追加されていることを確認して終了します。

手順⑬パスが通っているか確認するためコマンドプロンプトを起動して、以下のコマンドを実行します。

>openssl version

バージョンの情報が表示されていれば成功です。

OpenSSL を使用して非公開鍵と自己署名デジタル証明書の作成

つぎにOpensslを使って自己署名デジタル証明書を作成していきます。（以下2つのファイルを生成します）

・server.key — 非公開鍵。auth:jwt:grant コマンドで組織を認証するときにこのファイルを指定します。
・server.crt — デジタル証明書。JWT ベアラーフローで必要な接続アプリケーションを作成するときにこのファイルをアップロードします。

手順①コマンドプロンプトを起動して、非公開鍵を生成するワークフォルダを作成します。

>　mkdir 任意のワークフォルダ（フルパスで指定）　※システム管理者権限が必要なフォルダ階層はやめたほうが良いです。

例：mkdirコマンドを使って以下のフォルダを作成して、cdコマンドで作成したフォルダへ移動します。

</p>
<p>> mkdir C:\Users\e\dev\jdoe\JWT</p>
<p>> cd C:\Users\e\dev\jdoe\JWT</p>
<p>

※エクスプローラからフォルダを作成しても構いません。

手順②以下のコマンドを実行して非公開鍵を生成し、server.key というファイルに保存します。

</p>
<p>> openssl genrsa -des3 -passout pass:SomePassword -out server.pass.key 2048</p>
<p>> openssl rsa -passin pass:SomePassword -in server.pass.key -out server.key</p>
<p>

手順③上記コマンド実行後、作業用フォルダに以下2つのファイルが生成されているため[server.pass.key]のほうを削除します。

・server.key

・server.pass.key

手順④server.key ファイルを使用して、証明書署名要求を生成します。（server.csr というファイルに証明書署名要求を保存）

以下のコマンドを実行します。

</p>
<p>> openssl req -new -key server.key -out server.csr</p>
<p>

以下、会社情報などの情報入力が求められるため適宜ご自身の情報を入力してください。

</p>
<p>>openssl req -new -key server.key -out server.csr<br />
You are about to be asked to enter information that will be incorporated<br />
into your certificate request.<br />
What you are about to enter is what is called a Distinguished Name or a DN.<br />
There are quite a few fields but you can leave some blank<br />
For some fields there will be a default value,<br />
If you enter ‘.’, the field will be left blank.<br />
—–</p>
<p><span style="color: #99ccff;">Country Name (2 letter code) [AU]:JP</span><br />
<span style="color: #99ccff;">State or Province Name (full name) [Some-State]:TOKYO</span><br />
<span style="color: #99ccff;">Locality Name (eg, city) []:KOTO-KU</span><br />
<span style="color: #99ccff;">Organization Name (eg, company) [Internet Widgits Pty Ltd]:CCLT</span><br />
<span style="color: #99ccff;">Organizational Unit Name (eg, section) []:IT</span><br />
<span style="color: #99ccff;">Common Name (e.g. server FQDN or YOUR name) []:CCLT</span><br />
<span style="color: #99ccff;">Email Address []:cclt@mail.com</span></p>
<p><span style="color: #99ccff;">Please enter the following ‘extra’ attributes</span><br />
<span style="color: #99ccff;">to be sent with your certificate request</span><br />
<span style="color: #99ccff;">A challenge password []:　※パスワードを設定</span><br />
<span style="color: #99ccff;">An optional company name []:CCLT</span></p>
<p>

手順⑤以下のcsrファイルが生成されていることを確認します。

server.csr

手順⑥以下のコマンドを実行し、server.key および server.csr ファイルから自己署名デジタル証明書を生成します。

※server.crt というファイルに証明書を保存します。

</p>
<p>> openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt</p>
<p>（実行結果）<br />
Certificate request self-signature ok<br />
subject=C = JP, ST = TOKYO, L = KOTO-KU, O = CCLT, OU = IT, CN = CCLT, emailAddress = cclt@mail.com</p>
<p>

※非公開鍵： server.key とデジタル証明書： server.crt が存在することを確認します。

接続アプリケーションを作成して Salesforce DX 用に設定

OAuth 2.0 JWT ベアラー認証フローを使用して、Dev Hub 組織にCircleCI用の接続アプリケーションを作成します。

Dev Hub 組織用の接続アプリケーションの作成

手順①Dev Hubを有効化したSalesforce組織にログインして、[設定] から、アプリケーションマネージャを実行します。

手順②接続アプリケーション名などの情報を入力して、OAuth 設定の有効化にチェックを入れます。

※OAuth にチェックを入れるとOAuthの設定情報を入力できるようになります。

• コールバックURL：「http://localhost:1717/OauthRedirect」を入力します。
• デジタル署名を使用：JWT認証の場合こちらをチェック
• 証明書ファイルのアップロード：ローカル環境で生成したserver.crt をアップロードします。

手順③OAuthの範囲は以下を選択します。

• API を使用してユーザデータを管理 (api)
• Web ブラウザを使用してユーザデータを管理 (web)
• いつでも要求を実行 (refresh_token, offline_access)

上記を設定後、保存をクリックします。

手順④保存後の画面に表示されるコンシューマ鍵をコピーしてテキストに張り付けておきます。※後で利用するため

手順⑤manageボタンをクリックして、ポリシーの編集画面にて、[ポリシーを編集] をクリックします。

手順⑥ [OAuth ポリシー]の許可されているユーザで [管理者が承認したユーザは事前承認済み] を選択します。

以下の警告メッセージが表示されるためOKをクリックします。

手順⑦上記の設定が完了したら保存します。

手順⑧プロファイルを管理するのメニューを実行します。

手順⑨この接続アプリケーションを許可するプロファイルを選択して保存します。

※プロファイルの選択の代わりに権限セットを作成して、ユーザへ付与しても構いません。

手順⑩認証する組織が https://login.salesforce.com でホストされていない場合、プロジェクトの設定ファイル (sfdx-project.json) を更新する必要があります。

sfdx-project.jsonファイルは、Salesforce CLIをインストールしたフォルダ内にあります。

C:\Program Files\Salesforce CLI\client\node_modules\@salesforce\templates\lib\templates\project\sfdx-project.json

sfdx-project.jsonファイルを開いて、URLを書き換えて保存します。

https://test.salesforce.comの場合、sfdcLoginUrlの箇所を”sfdcLoginUrl”: “”とする。

手順⑪コマンドプロンプトを起動して以下のコマンドを実行し、接続アプリケーションのクライアント ID (コンシューマ鍵)、非公開鍵ファイル (server.key) へのパス、および JWT 認証ユーザ名を指定します。

>sfdx auth:jwt:grant –clientid （手順④でコピーしておいたコンシューマ鍵を指定） –jwtkeyfile （server.keyをフルパスで指定） –username （SalesforceへのログインユーザIDを指定） –setdefaultdevhubusername –setalias （エイリアス名を指定）my-hub-org

実行例：

</p>
<p>>sfdx auth:jwt:grant –clientid 3MVG95mg0lk4batiP7Q5f8gZVROjIpEdZT –jwtkeyfile C:\Users\e\dev\jdoe\JWT\server.key –username cclt.sfdc@mail.com –setdefaultdevhubusername –setalias my-hub-org</p>
<p>

※ –setdefaultdevhubusername パラメータを指定するとDev Hub 組織を認証するときにデフォルトに設定されます。

サーバキーの暗号化

続いては、server.keyファイルの暗号化を実施します。※鍵と初期化ベクトル (iv) を生成して server.key ファイルを暗号化する。

CircleCI 側では、ここで利用する鍵と vi を使ってビルド環境でサーバキーの復号化を行います。

手順①コマンドプロンプトを起動して、server.keyファイルを生成したフォルダへ移動します。

</p>
<p>>cd \server.keyファイルがあるディレクトリのフルパスを指定</p>
<p>

手順②以下のコマンドを実行します。※<passphrase> は、一意の鍵を作成するためのフレーズを指定します。

</p>
<p>> openssl enc -aes-256-cbc -k <passphrase> -P -md sha1 -nosalt</p>
<p>

実行すると生成された鍵（key)とivベクトルが表示されるので、テキストに張り付けて保存しておきます。

</p>
<p>C:\Users\e\dev\jdoe\JWT>openssl enc -aes-256-cbc -k <password> -P -md sha1 -nosalt<br />
*** WARNING : deprecated key derivation used.<br />
Using -iter or -pbkdf2 would be better.<br />
key=6431BAAE651D440343874873ADE64EB02B5311DAAF550BDD67A8C9892…<br />
iv =3F8DB47ADD8BF92D751EE0B2BEF…</p>
<p>

手順③上記手順②で生成されたkeyとivを使ってserver.keyファイルを暗号化します。

コマンドプロンプトで以下のコマンドを実行します。※フォルダは上記鍵を生成したところで実行すること。

>openssl enc -nosalt -aes-256-cbc -in server.key -out server.key.enc -base64 -K <key> -iv <iv>

<key>は、手順②で生成してkeyを指定し、<iv>は、手順②で生成したivを指定

実行例

</p>
<p>C:\Users\e\dev\jdoe\JWT>openssl enc -nosalt -aes-256-cbc -in server.key -out server.key.enc -base64 -K 6431BAAE651D440343874873ADE64EB02B5311DAAF550BDD67A8C9892… -iv 3F8DB47ADD8BF92D751EE0B2BEF…</p>
<p>

まとめ

今回の記事では、JWTベースフローを使用した組織の認証で、非公開鍵と自己署名デジタル証明書の作成からサーバーキーの暗号化までの手順について説明しました。

次回は、CircleCI を DevHub に接続から最後のCircleci での自動ビルドまで説明していきます。もう一息ですね。

参考

CircleCIを使った継続的インテグレーション（Continuous Integration）第3回

第二回では、JWTベースフローを使用した組織の認証で、非公開鍵と自己署名デジタル…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

これらの作業を自動化することで、作業工数の削減や品質の向上（手作業によるミスの低減）を実現することができます。

以前は、Salesforceの継続的インテグレーションの実現方法が、Jenkinsを使ったCIが主流でしたが、最近ではほかにもいくつか推奨されるものが出てきています。

• CircleCI + Salesforce
• Jenkins + Salesforce
• Travis CI + Salesforce

詳細は、以下Salesforce公式サイトを参照ください。

今回は、これらの中からCircleCIを使った環境構築手順についてご説明していきたいと思います。

作業手順

まずは、簡単に全体の流れを説明します。

GitHubのサインアップ

本記事をご覧になっている方のほとんどは、おそらくGithubをすでに使っている方ばかりだと思いますが、初めての方もいらっしゃるかもしれませんので、GitHubのセットアップ手順について説明させてい頂きます。

GitHub（ギットハブ）とは、プログラムのソースコードなどのリソースファイルをバージョン管理（保存）したり、公開するためのクラウドサービスとなります。もちろん非公開として自分だけやプロジェクトメンバーだけアクセスさせるような利用も可能です。

現在では、世界中のエンジニアの方が自身が作成したプログラムを公開していて、自分のスキルを証明するための資産として利用している側面もあります。Salesforce関連の非常に有用なソースコードも多数公開されているため、新しい機能を作るときには一度探してみるのもよいかもしれません。

セットアップ手順

手順①以下のサイトへアクセスします。

手順②公式サイトから「Sign up」ボタンをクリックします。

手順③アカウント作成画面にて以下の情報を登録する。

• ユーザ名（Username）
• Email address（メールアドレス）
• Password（パスワード）
• Verify your account（指定の画像を選択する）
• Create Accountボタンをクリックして完了

手順④登録したメールアドレスに以下のメールが届くため、メール内のリンクをクリックして認証を行います。

手順⑤認証が完了するとログイン後の画面が表示されます。

手順⑥新規リポジトリ（リソースを登録するスペースのこと）を作成します。※すでにお持ちの場合は省略

画面右上の＋メニューから「New repository」をクリックします。

手順⑦以下の内容を入力して、Create Repositoryボタンをクリックします。

• Repository name:リポジトリ名
• Description（説明）
• 公開設定：Public（公開）/Private（非公開）
• Add a README File：Readmeファイルを作成するかどうか

手順⑧リポジトリが作成されると以下のように表示されます。

この後は、リポジトリにソースコードを登録する作業がありますが、CircleCIの環境セットアップを先に実施します。

※CircleCIはGitHubやGitBucketなどと連携できますが、今回はGithubを利用します。

CircleCIの環境構築（CircleCI で GitHub リポジトリを設定）

まずは、CircleCIのサインアップから行っていきます。

手順①以下、ブラウザでCircleCIの公式HPを開きます。

手順②ホーム画面トップメニューにある「Sign up」ボタンをクリックします。

手順③サインアップ画面では、以下3種類の認証が用意されています。

今回は先ほどセットアップしたGithubの認証を使うので、「Sign up with GitHub」を選択してください。

手順④GitHubのログイン画面が表示されるため、セットアップしたアカウントでログインします。

手順⑤Autorize CircleCIの画面が表示されます。リポジトリのアクセス権限や個人データ（メールアドレス）に対するアクセス権限を求められるため問題なければ「Authorize CircleCI」をクリックします。

手順⑥セットアップ画面では以下の内容を登録して、Setup Projectを実行します。

• Select Organization：GitHub組織を選択
• Select Repository：リポジトリを選択
• Select your config.yml file：config.ymlファイルを選択（存在しない場合は2番目のオプションを選択します。）

手順⑦セットアップが完了すると以下の画面が表示されます。

GitHubを確認するとCircleCIから作成されたBranchが確認できます。

Salesforce CLIのインストール

Salesforceのコマンドラインインタフェース（CLI）については、インストールが必要となりますので、ご利用中のOSに合わせて

公式サイトからダウンロードしてインストールを実行してください。

詳細な手順はこちらの記事を参照ください。

参考

Salesforce CLI（Command Line Interface）の利用ガイド

本記事では、Salesforceが提供するCLI（Command Line In…

続きを読む

Dev Hub の有効化

Dev Hubを有効化するとスクラッチ組織の作成と管理、第二世代パッケージの作成と管理、Einstein 機能が利用可能となります。

注意：Sandbox で Dev Hub を有効にすることはできません。そのほか制約事項や注意点は、Salesforce公式HELPサイト「組織のDev Hub機能の有効化」を参照してください。

ではDev Hubを有効化していきましょう。

手順①Salesforceにシステム管理者でログインして、設定->Dev Hubを実行します。

手順②Dev Hubの設定画面にて、Dev Hubを有効化を実行します。

注意: 一度有効化すると元に戻す（無効化）することができないので注意！

まとめ

今回は、GuthubのセットアップからCircleCIのセットアップ、そしてGitHubとの連携と、DevHubの有効化までの手順をご説明しました。

次回は残りの手順についてご説明していきます。Salesforceの組織とCircleCIの認証に関する設定をしていくことになりますが、内容としてはこれまでよりも難しい内容となりますが、頑張って設定していきましょう。

参考

CircleCIを使った継続的インテグレーション（Continuous Integration）第2回

第一回では、GuthubのセットアップからCircleCIのセットアップ、そして…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村