とあるStartupに勤めるエンジニアの技術ブログ

Salesforce、テスト関係の技術ブログなどを書く予定

Salesforceで項目履歴をDIYする!

今年も技術系アドベントカレンダーの季節がやってまいりました。皆さま元気にお過ごしでしょうか?

今年はコロナ禍のため Dreamforce もリアルイベントではなく、バーチャル開催となりました。バーチャル開催となることでこれまで参加できなかった人も参加できるようになりました。どんなイベントになるか楽しみです。
www.salesforce.com

さて、今年も技術系アドベントカレンダーがクリスマスまで25日間続きます。今日から毎日投稿されるアドベントカレンダーの記事を読んで楽しみましょう!

はじめに

エンタープライズでは項目の監査履歴を求められることがあります。Salesforce Shieldで提供される項目監査履歴を利用するのが定跡ですが、有償機能にしないと制限があり、かつ有償機能を利用しても60項目までしか履歴を追跡できません。

そこで、今回は項目履歴をDIYしてみましょう。

項目監査履歴

まず、標準的に利用できる項目監査履歴についてです。
Salesforce Shield で提供される機能となり、設定した項目監査履歴保持ポリシーにしたがって項目履歴をアーカイブしていきます。Salesforce Shield は有償機能ですが、無償でも一部の機能を利用できます。

有償の場合
・1 オブジェクトにつき60個までの項目追跡
アーカイブされた時点から最長 10 年保持

無償の場合
・1 オブジェクトにつき20個までの項目追跡
アーカイブされた時間から 18 ヶ月

より詳細はSalesforceセキュリティガイドなどを参考にしてください。
developer.salesforce.com

項目履歴をDIYする

さて、ここからは項目監査履歴を利用してもいろいろと制約があるため、せっかくなのでDIYしていきます。

今回利用する機能は、変更データキャプチャとBig Objectになります。普段聞き慣れない機能なので、簡単に紹介していきます。

変更データキャプチャ

変更データキャプチャはSalesforce データを外部データと効率よく統合できるようにするための機能です。詳しくはTrailheadのモジュールを学習してもらうと理解できると思います。

今回は、例外的な使い方になりそうですが、カスタムオブジェクトの作成・更新・削除・復元のイベントでログを記録するために利用します。通常のApexトリガーでもよいのですが、変更された項目が取得しやすいので使ってみました。
trailhead.salesforce.com

Big Object

Big ObjectはSalesforce Platform 上で大量のデータを保存して管理するための機能です。用途としては、顧客の360度ビュー、監査と追跡、履歴アーカイブなど、まさに今回の用途に利用することが想定されています。
trailhead.salesforce.com

設計

設計としては下図のようになります。

f:id:a-kura:20201201234700p:plain
設計図

項目履歴を記録した対象のカスタムオブジェクトに変更データキャプチャの設定、およびChangeEventに対するApexトリガーを設定します。このApexトリガー内で履歴データを作成し、BigObjectに書き込みます。

変更データキャプチャを利用すると強制的に非同期実行となるため、同期処理に負担をかけず処理できるところがよいところです。今回のケースでは、Big Objectへの書き込みも非同期処理となってしまい、やりすぎな感じがします。

実装

続いて、実装になります。ChangeEventHeaderに更新操作で変更された項目のリストであるchangedfieldsがあり、変更点のログの組み立てが簡単にできるようになっています。

trigger ChangeCustomObjectChangeTrigger on ChangeCustomObject__ChangeEvent (after insert) {
   List<FieldHistory__b> historyList = new List<FieldHistory__b>();
   
	for (ChangeCustomObject__ChangeEvent event : Trigger.New) {
    	EventBus.ChangeEventHeader header = event.ChangeEventHeader;
        
        FieldHistory__b history = new FieldHistory__b();
       
        switch on header.changetype {
            when 'INSERT' {
                // 追加時に記録するログを組み立てる
            }
            when 'UPDATE' {
                // 更新時に記録するログを組み立てる
            }
            when 'DELETE' {
                // 削除時に記録するログを組み立てる
            }
            WHEN 'UNDELETE' {
                // 復元時に記録するログを組み立てる
            }
        }
        historyList.add(history);
    }
    if(historyList.size() > 0) {
        Database.insertImmediate(historyList);
    }
}

カスタムオブジェクトの項目値の変更をJSON形式に変換して履歴として保存しておくことで項目履歴が記録できるようになります。時間の関係でJSON形式の文字列を組み立てるコードは割愛させてもらっています(作業時間が取れれば追記します)。

おわりに

変更データキャプチャとBigObjectを利用した項目履歴のDIYについてご紹介しました。

正直なところ、変更データキャプチャはオーバーエンジニアリング気味です。本来、変更データキャプチャはサービス間のイベントをストリーミングでやりとりします。SalesforceではこれをApexトリガーで扱え、複雑な実装なしで利用できる点は非常に優れていると感じました。

プラットフォームイベントと合わせて、難易度の高かったサービス間連携が比較的簡単に実装できそうです。今回は技術に触ってみるといったところまででしたが、利用方法を研究していきたいと思います。

Enjoy Advent Calendar!


この記事は、 note.com に投稿した記事の転載になります。
note.com

ノーコード/ローコード開発時代における技術選定

はじめに

先日のテラスカイ横山さん、TAOドライブ米井さんとの収録で、Salesforceでのノーコード/ローコード開発とプロコード開発の技術選定の基準について話しました。

migration.fm

とても複雑な問題であり、その場はあまり深く踏み込まずに終わりました。その後、独りで掘り下げて考えてみたので、私なりにエッセンスをまとめたいと思います。

 

技術選定基準

技術選定するために必要なことはなんでしょうか?
今回はノーコード/ローコードで開発すべきか、プロコードで開発すべきか、どちらにすればよいかを判断するための基準が必要だと考えました。

 

私が考えた技術選定の基準は下記の3つになります。

  1. 価値 Value
  2. 複雑さ Complexity
  3. 技術力 Technical Capabilities
続きを読む

Salesforceにおける継続的ノーコード開発のベストプラクティス

はじめに

先日のMiryさんとの収録でSalesforceでのノーコード開発で実践すべきプラクティスを伺うことができました。

migration.fm

Salesforceを活用しきる点において非常に先行する取り組みをされており、さまざまなノウハウがあることがわかりました。Podcastという音声メディアではググラビリティ(検索性)に劣るので、私なりにエッセンスをまとめたいと思います。

ベストプラクティス

ビジネスが成長する中でSalesforceを利用したノーコード開発を継続するためのベストプラクティスを下記の3点にまとめました。

  1. ノーコーディングルール
  2. ドキュメンテーション
  3. リファクタリング

以下では、それぞれのプラクティスについて掘り下げていきます。

ノーコーディングルール

ノーコードにおいても設計指針を策定することが重要です。
決めていくことはさまざまありますが、例えばトリガー系処理の優先順などです。

具体的にはトリガー系処理を下記のような優先順に取り決めます。

  1. 数式
  2. ワークフロールール
  3. プロセスビルダー
  4. フロー
  5. Apexトリガー

このような優先順にしている理由として、「できるだけSalesforce Adminが理解・対応できるようにして開発エンジニアではなくても対応する」という考えがあります。これによって、プログラミングできないようなビジネス寄りの人が設定変更できるようになり、業務と開発の両方を理解した人が作業することで適切な要件の落とし込みが素早くできるようになります。

なぜ、このようなルールが必要なのかというと、開発エンジニアは慣れているプロコードの方が楽なのでルール化しておかないとSalesforce Adminが理解・変更できる領域が狭まってしまいます。そのため、この方針を背景とともにメンバーが理解し、設定を考える上での具体的なルールに落とし込むことが重要になります。

ドキュメンテーション

Salesforceの設定は簡単に変更できるため、ついその場の対応で設定を変更していきがちです。そういった場当たり的な対応を続けていると、下記のような負の連鎖が起きてしまいます。

まず、現在Salesforce組織にどういった設定がされているか分からなくなります。記憶力がいい人がすべてを把握して対応していれば、まだ管理できた状態を保てます。しかし、歴史が長くなり忘れてしまったり、別の人が対応することになったりすると問題が表出してきます。

このような状態では、現在の設定がどういった経緯で設定されたか分からないため、安易に変更できなくなり、下記のような問題が発生してきます。

まず、既存の設定を変更するために経緯を確認し、影響範囲を調査する作業が必要となるため、設定変更に時間がかかってしまうことです。Salesforceでは設定画面を操作して設定していくため、関連する設定を探しにくいところがあります。

次に、そのような調査や検討が飛ばされてしまうことです。調査する時間が取れないため、時間のあるときに見直そうと現在の設定に影響しないように追加で設定ししてしまうことです。しかし、こういった負債は日々の作業に追われて返済されることなく溜まっていくことになります。

最後の問題は、継ぎ接ぎだらけの設定になることで複雑化してしまうことです。複雑化してしまった設定のメンテナンス性は低下し、処理も遅くなってしまいます。

このようにして、設定は日々肥大化し、複雑化していきます。では、このような状態にならないようにするためにはどのようにすればよいのでしょうか?

設定が肥大化・複雑化していく問題に対する万能な解決策「銀の弾丸」はありません。地道なエンジニアリングで負債を溜めないようにしていくしかありません。
その中でもドキュメントを残すプラクティスが重要です。ドキュメントに過去の経緯や影響範囲などがまとまっていることで上記のような問題が起こりにくくなります。ドキュメントベースで他の人とレビューしたり、共有したりできるようになります。

このようにドキュメンテーションしていくことで、肥大化・複雑化しがちな既存の設定を見直し最適な状態に保つ礎を築くことができます。

リファクタリング

ドキュメンテーションのプラクティスでも触れましたが、ノーコード開発を継続するためにはメンテナンス性を高い状態に保つことが重要です。

ドキュメンテーションによって日頃から肥大化・複雑化する設定を増やさないことも重要ですが、日々忙しくしているとどうしても負債が蓄積されていってしまいます。また、ビジネスの変化によって不要となる設定や項目があったり、新しい機能がリリースされることでより良い設定ができるようになったりします。

そのため、定期的に時間を確保して、既存の設定や項目を見直す作業「リファクタリング」を実施することが重要です。
リファクタリングでは下記のようなことを実施します。
1. 不要になった設定や項目がないか確認する
2. 肥大化・複雑化している設定を簡潔に直せないか考える
3. 新しい機能で利用できるものがないか考える

Salesforceの設定はビジネスに合わせてスピード優先で走りながら直していく側面もあります。ビジネスの変化が落ち着いたところで設定を最適化した方がよい局面もあるので、リファクタリングをプロセスに取り込んでいくことでメンテナンス性とスピードのバランスを取ることが重要です。

今後の課題

Salesforceにおける継続的ノーコード開発において課題と考えていることが2点あります。

テスト

Miryさんも話していましたが、ノーコードで開発した物はマニュアルテストを頑張って実施していくしかありません。開発物が増大すると影響範囲も広くなり、既存の設定に影響ないことを確認するためのマニュアルテストの負担が増えていきます。

テスト自動化ツールを利用して、マニュアルテストの一部を自動テストに置き換えていく、などの取り組みも必要になると考えます。

構成管理

Salesforceの設定の構成管理をどのように実施していくか、はまだ解決できていない課題だと考えています。SalesforceDXによってメタデータの取り扱いやソースコード管理ができるようになってきていますが、まだ開発エンジニア向けの機能であり、Salesforce Adminが扱うには難しいのが現状です。

SalesforceDXの機能拡充が進み解決していくとは思いますが、それまでは工夫して対応していく必要があると考えます。

まとめ

この記事では、継続的にノーコード開発を実践するためのベストプラクティスとして、ノーコーディングルール、ドキュメンテーションリファクタリングを紹介しました。

一貫する考え方としては、エンジニアリング手法を導入しながら Salesforce Admin をエンパワーメントすることです。今後ますます Salesforce Platform が強力になることで業務要件を簡単に開発できるようになっていき、Salesforce Admin によるノーコード開発はより広く実践されていくことになります。しかし、ノーコード開発は開発モデルがまだ成熟しておらず、このようなベストプラクティスが蓄積されていくことが重要だと感じました。

この記事は、 note.com に投稿した記事の転載になります。
note.com

Japan Dreamin’ 2020 登壇してきた!

遅くなりましたが、2020年1月25日(土)に開催された Japan Dreamin' 2020 に参加・登壇してきました。 

今回の発表では、AppExchange プロダクトを継続して開発していく中で注意すべき点について話しました。こちらから資料を見ることができますので、よろしければご覧ください。

www.slideshare.net

Japan Dreamin' 2020

Japan Dreamin’2020 での発表資料を参照できるものもあります。さまざまなテーマで発表されており、参考になる発表も数多くあると思いますので、ご自身の興味のあるテーマを探してみていただければと思います。

www.japandreamin.com

続きを読む

Salesforce Evergreen に夢を見る

今年も技術系アドベントカレンダーの季節がやってまいりました。皆さま元気にお過ごしでしょうか?

先日 Dreamforce が開催され、まだ時差ぼけが治っていない方も多いかもしれませんが、クリスマスまで25日ですので、今日から毎日投稿されるアドベントカレンダーの記事を読んで楽しましょう!


この記事は Salesforce Platform Advent Calendar 2019 - Qiita 第1日目の投稿です。

qiita.com

はじめに

今年は Dreamforce では Developer 向けに大きな発表がありました。

そうです。

Salesforce Evergreen です。

Salesforce Evergreen とは?

Salesforce Developer Blog の記事によると Customer 360 Platform の新しい機能です。また、Salesforce Evergreen はフルマネージドな Kubernetes 上に構築されたサーバレス機能(Functions-as-a-Service)、一般的に利用される高性能なデータストア(マネージドデータストア)を提供します。

Salesforce Evergreen で何が変わるのか?

Salesforce プラットフォームでは苦手としていたことについて、解消されることが期待されます。その苦手なこととは下記のようなものです。

1. 重い処理を実行すること
2. 複雑なアーキテクチャを実装すること
3. 既存資産を活用すること

重い処理を実行する

Salesforce Evergreen では Function-as-a-Service によって機能を実装することができます。Saleasforce プラットフォームではマルチテナントを実現するためにサーバー処理能力を占有するような重い処理を実行することが苦手でした。 

Salesforce Developer の多くを苦しめているガバナ制約などの制限となります。Salesforce プラットフォームでも重い処理は非同期的に実行することで回避できることもありますが、それでも重い処理は Heroku や Amazon EC2 などの外部サービスにオフロードしていました。

今回発表された Salesforce Evergreen では、上記のようにして回避していた課題を Function-as-a-Service として実装することでよりシームレスに開発できるようになります。

 

Low Code で Salesforce 製品の機能を自社にフィッティングするだけであれば、既存の Apex を利用して Salesforce プラットフォームに実装しても大きな問題はありません。

しかし、AppExchange に登録されているような業務システム製品では勤怠計算処理、会計集計処理など計算量が多い機能がありますが、Salesforce プラットフォームの制約のため機能の一部を妥協していることもあります。

Salesforce Evergreen を利用することでより複雑・高負荷な機能を実装できるようになり、より優れた機能を提供できるようになることが期待できます。

複雑なアーキテクチャを実装する

Salesforce プラットフォームはすべてのプログラムを一つのものとして管理してしまいます。Salesforce DX CLI を使ったり、第2世代管理パッケージを利用したりすることで分割して管理できるようになってきていますが、Microservices まで分解して管理することはできませんでした。 

Salesforce Evergreen を利用することで機能を独立的に管理できるようになります。これによって開発するチームの責任分担もやりやすくなります。また、アーキテクチャも自由に設計できるようになるため、複雑な問題に対処するためにリッチなクラス構造を整えることができます。

 

加えて、Apex ではできなかったローカル開発が可能になり、ローカル環境で実行できる自動テストを実行できるようになります。Apex テストではテスト実行に時間がかかってしまっていた処理も継続的インテグレーション環境を構築し、並行実行することで時間短縮も可能になります。自動テスト環境は開発者にとっての基本的人権とも言えるところなので、この部分が大きく改善することは大きな意味があります。 

既存資産を活用する

Salesforce プラットフォームでは開発言語が Apex に制限されるため、Javaなどで開発した既存資産は利用できませんでした。Salesforce プラットフォームに業務システムを寄せようとした場合、必要な業務システムは Salesforce プラットフォーム上にすべて再構築する必要がありました。 

Salesforce Evergreen を利用すると JavaScript / Javaソースコードを実行できるため、既存資産にあるビジネスロジックを流用することができます。 

それ以上に既存資産として有効活用できるものとして、インターネット上に多く公開されているライブラリやフレームワークです。Salesforce プラットフォームではライブラリを一元管理する仕組みがなく、個別に再実装したり、ソースコードをコピーして利用していました。

パッケージ管理ツールで利用しているパッケージをインポートして利用できるようになれば、余計なソースコードの管理が削減できることは開発生産性にも効果的です。

Apex は生き残るのか?

さて、皆さん気になっていることではないでしょうか?

Evergreen の登場によって、Apex がオワコンになる可能性が高まってきますが、将来的には必要なくなってしまうのでしょうか?

 

私の答えは「なくならない」です。

 

なぜか?

それは、Microservices が通常の開発ではオーバースペックだからです。ちょっとインテグレーションしたい場合にそこまでやってしまうと構築コストが跳ね上がってしまいます。"No Code" では実現しきれなかった処理で、"Low Code" で実現するスクリプト言語としてはなくならないと思います。

 

では、その構築コストに見合う開発を行なっている人たちは誰か?

SIer の一部もそれに見合う人たちもいると思いますが、一番活用するのは AppExchange にプロダクトを公開している ISV/OEM パートナーです。彼らは Salesforce プラットフォーム上に巨大な業務システムを構築しています。一枚岩のシステムは巨大になると管理コストが負担になってきたり、複数の開発チームで分担しにくくなってきます。

それらの問題を解決するための手段として、Microservices が発明され、大きなプロダクトを持つ企業を中心に広まってきています。そういった意味では、Salesforce Evergreen は ISV/OEM パートナーに向けた機能追加と言えるかもしれません。

しかし、ISV/OEM パートナーもすでに Apex で記述した大量の既存資産を抱えているため、Salesforce Evergreen に容易にはトランスフォームできません。このトランスフォームをうまく成し遂げた、または新たに参入して Salesforce Evergreen を使いこなした企業が大きく成長するのかもしれません。

おわりに

Dreamforce で Salesforce Evergreen が発表されたことを受けて、どういった影響がありそうか考えてみました。ISV/OEM パートナーとして開発しているものとしては新しい挑戦ができる楽しみ、と、やらなければ生き残れないのでは?という焦燥感を抱きました。

2020年2月には Developer Preview として実際に触れる環境が提供され始めます。まだまだこれから情報が増えていく段階ではあるので、楽しみにして待ちたいと思います。

 

最後に、アドベントカレンダーSalesforce Evergreen について何かを書こうと思っていた矢先に、stomita (id:shinichitomita) さんによるガチ分析なブログが公開されました。非常に鋭く面白い内容ですので、ぜひそちらもどうぞ。

 

Enjoy Advent Calendar!

Salesforce Webinar 「Salesforce DX の始め方とパートナー様成功事例」にゲスト出演しました

こんにちは。

1ヶ月も経っていまさらな感じですが、2019年8月30日に開催されたセールスフォース・ドットコム社主催のウェビナーにゲスト出演しました。

 

今回のウェビナーでは、SalesforceDX の活用事例を2社、co-meeting木村さんと私から話しました。こちらから資料と動画を見ることができますので、よろしければご覧ください。

developer.salesforce.com

www.slideshare.net

続きを読む

JSTQB ALTM に合格したぞい

8月25日にJSTQB認定テスト技術者資格 Advanced Level <テストマネージャー>を受験しました。

そして、10月に合格発表が…。
www.juse.or.jp

まったく合格できる気がしていなかったのですが、なんと合格できました!
よかったー。
昨日、合格証書も届き、ちゃんと合格したんだなぁ、と実感が湧きました。

「Full Advanced Level Professional:テスト技術者資格 Advanced Level 完全上級テスト技術者」の称号を得るためにはあとテクニカルテストアナリスト(ALTTA)が必要なのですが、日本語で出題されるJSTQBではまだ受験できません。

うーん、英語が身につくのが先か、日本で受験できるようになるのが先か…。

Enjoy Testing!