#はじめに
※この記事はSalesforce 開発者向けブログ投稿キャンペーンへのエントリー記事です。
最近は"ローコード"(とかノーコード)といったキーワードで、
「非エンジニアであってもシステムがつくれる！」ということに関心や注目が集まっていますが
Salesforceは長くITの民主化を掲げ、少なくとも10年以上前から
ローコードの開発プラットフォームを提供し続けており、
裏を返せば、この界隈では
"ローコードでシステムをつくるとは？そのシステムと共に活きるとはどういうことか？"
という知見や製品ならではのTipsは溜まっているはずで
この辺りの話はSalesforceに限らず
他のローコードプラットフォームを検討する上でも役に立つはずで
網羅的にとはいかないまでも、ちょこちょこと発信、情報蓄積していくべき分野だと思っています。
何が出来るか？ とか、どうやってやるか？
、はとっつきやすいですが、
やってみて困ることとか付き合い続けることのナレッジが
今後たくさん出てくると良いですね。
#今日のテーマ/想定読者
Salesforceのローコード開発を進めて、特にプロセスビルダーやフローなどの自動化処理
の辺りを開発/運用する中で見かける困りごとやその対処を記載します。
対象は、エンジニアというよりはAdmin寄り、
Salesforceのカスタマイズはある程度知っており
ローコード開発をしている、したことがある、学習していてまさにこれからやる方。
#(結論)やはり基礎が大事
###課題を体感し、学習し、改善を
プロセスビルダーやフローといった
ローコードの機能を活用して業務システムに組み込み、改善を進めていく
Adminの方や受託サイドのエンジニア/コンサルタントの方を支援していて思うのは
プログラミングは出来なくても、
"プログラミング的思考が出来る"
というのが素養として大事になる部分だと改めて思います。
コード書けなくても良いので、
ロジカルな世界で、 "適切な" 順次/判断/分岐処理で目的を達成する
__"アルゴリズム"__を作れることが基礎になります。
(そう言えば、エンジニアになる時、新人研修のかなり初めのほうに習いました。)
JavaやRubyが分からなくても、ローコードで構築したシステム運用の中で、
論理的にはこの画面のデータを使って、こんな順番に処理して番号振りたいとか、
似たような処理が沢山できちゃったから、まとめないと直す時いちいち同じことしないといけなくて大変だなとか、
ローコードはプログラミング"的"な課題を
非エンジニアにもプレゼントしてくれます。
是非身の周りのエンジニアにその課題を話してみてください。
「エンジニアの世界ではこんな考え方があってね」
と、設計原則、思想、デザインパターン、命名規則、変更管理・・・・
これまで取っ付き辛かったエンジニアリングのノウハウを
教えてくれて、それはスッと頭に入ってくるはずです。
今はローコード環境のおかげで、
「まず試し、課題にぶつかり、改善する」
その中で運用保守性を考えて適切な設計や仕掛け、
というものを体得するリバースハックが出来る状態にあるので、
社会に出てから大学に戻って勉強したくなるあの感じを短いサイクルで回せる環境です。
とはいえ、転びすぎてもしんどいと思うので、
特に困ったこといくつか記載しておきます。
どこかでお役に立ちますように。
#Salesforceのローコード開発の難しさ
非常に拡張性が高いプラットフォームなので
画面の制御から、処理の制御までカスタマイズが多岐に渡り、選択肢も多く
「これをやりたいんだけど・・・」と相談すると
答えが選択肢として3個も4個も帰ってくる世界です。
どれをやればいいのか・・・
中でも、データの制御に関するカスタマイズは
入力規則、ワークフロー、プロセスビルダー、フロー・・・と多岐に渡り、
その中にも更にバリエーションがあります。
また、従来のシステム開発でも、新規開発時には手軽にできた変更も
徐々に改修していくスピードが落ちたり、
ちょっとした改修でも既存システムの影響調査や
テスト工数が上がってコストが高くなる、
というのはローコードプラットフォームでも起きます。
実装ハードルが低い分、実装する方のレベルや前提知識もマチマチになりがちで
ローコードでもシステムの機能はスパゲッティ化していきます。
###ローコードプロダクトを選ぶ観点、補完すべきこと
上記のように、ローコードだろうがなんだろうがシステムが時間とともに抱えていく課題は変わりません。
非エンジニアを対象にしていくという観点で
こうした活用後の課題は、プロダクトとしてある程度は想定されることなので
-
独自のハードルや縛りによって、スパゲッティや非効率になりづらいようになっている
-
なってきてもある程度の可読性や改善しやすい管理機能がある
-
(当たり前ですが)ナレッジやサポートがしっかりしてる
といったあたりは、"機能として出来ること"以上に
今後出てくるローコード製品を評価する観点として重要なものだと思います。
簡単にできる、は当たり前。
実はアプリ構築上のとっつき易さや、簡易さではSalesforce以外に軍配があがることが多そうですし
カスタムアプリに閉じたライトユーズのみであればSalesforcePlatformである必要もなさそうです。
上記したような観点を加えると、Salesforceをおすすめすることが多くなります。
簡単なもの程乱立しやすい性質があるので、
選定は奥が深いですね。
###（Salesforce難所)プロセスビルダーやフローに尽きる
この図はちょっと前にTwitterに貼ったものですが
今はSummer'20にバージョンがあがってフローも起動タイミングの種類が増えてますし
プロセスビルダーの上位互換な形に向かって進化もしております・・・
<ご留意ください>最新の情報を取り込めていないのと、検証できておらず、多重起動や再評価時の動きなどは間違っている箇所があるはずです
https://twitter.com/yonyonsaeki/status/1285247892697972736?s=20
---2022.06.27 追記---
以前よりお世話になっている海外サイトに素晴らしい図解のまとめがありました。
SalesforceBen.com "Learn Salesforce Order of Execution [Infographic]",2 May 2022
https://www.salesforceben.com/learn-salesforce-order-of-execution/
※もちろん公式サイトではないので、参照と利用にあたっては公式最新の情報と併せてご確認ください。
お伝えしたかった点は、
様々なローコードカスタマイズや、一部のコード開発が増えて絡み合うと
どんな順番で、何が動くのかがカオスになるということと、
正確に仕様把握が難しいということです。(僕の読解力の無さもあります)
トラブルが増えます。
また、トラブルがあっても原因究明や設定の改善箇所を特定する困難さが増します。
ちなみに、データ保存前後に動かせる処理の公開仕様の最新は開発者ドキュメントに記載があります。
が、正確に読み取るのが難しい複雑さがあります。
また、
フロー処理の一部で失敗したけど、部分的な更新が許可されていたため
そこだけロールバック(処理開始する前に巻き戻し)されず処理全体は完了する・・・
みたいなことも今後起きるので、現場から想定と違うデータがある、
と言われても何が起きてるのか、かなり戸惑うと思います。
https://releasenotes.docs.salesforce.com/ja-jp/summer20/release-notes/rn_forcecom_flow_mgmnt_partial_save_cruc.htm
実際、運用を数年単位で重ねられ、データやカスタマイズが積み重なっていくと
解決しづらい問題がおきやすいのは、
このデータ保存前後の処理を制御していく
- プロセスビルダー
- フロー
のあたりになっていきます。
図など見て頂いて、なんとなく問題おきそう・・・
無限ループ的なことして壊したらどうしよう・・・(壊れませんが)
など少しだけ怖い気持ちを持ちつつ、
その"リスク"を認識し、その上で強力な仲間として付き合っていくんだ、
と前向きに思って貰えればと思います。
#プロセスビルダーやフローが増えてくると・・・
###管理画面の使いづらさも考慮
オブジェクトが増えてきて、オブジェクト間のリレーションも増えてくると
オブジェクト間でデータのやりとりをしたいケースが増えてきます。
そこで直感的なプロセスビルダーでサクッと対応を重ねる訳ですが
その分増えたプロセスを管理する必要性がでてきます。
###この辺が使いづらい・・・
プロセスビルダーの管理画面は(現状2020/09時点)では、まだまだ使いづらいです。
本数が増えてくると、数十本という組織もざらにあります。
お目当てのプロセスビルダーを探し当てる手間や、
エラーメールが飛んできた時に、該当するAPI名のプロセスはどれ？とか
エラー対象のフローがどのプロセスから呼ばれてるかな？
と調べる時など結構難儀します。
命名ルールや台帳なども地味に大事
こじれちゃったら台帳化した方が、修正入れる時の影響範囲の把握とか、
エラーあった時に調査対象のアタリつけるとかでは便利かもしれません。
ラベル名でソートされる管理画面なので、オブジェクト名とか、起動タイミングとかで
プロセス名つける際のルールをつけてあげるのも、理解を早めると思います。
###そもそも増やさない、ということも・・・
公式のベストプラクティスでは、「1オブジェクトにつき1プロセスにする」ことを推奨されています。
<プログラム設計のペストプラクティス>
〜オブジェクトあたり 1 つのレコード変更プロセスのみにする。〜
https://help.salesforce.com/articleView?id=process_considerations_design_bestpractices.htm&type=5
レコードが作成または更新されるたびに、そのオブジェクトのすべてのレコード変更プロセスが評価されます。組織でオブジェクトあたり 1 つのレコード変更プロセスに制限することをお勧めします。
図にするとこんな感じですかね。
とはいえ、手軽に、サクッと、時間をかけられないので、継ぎ足しされやすい性質があります。
ただ、次の項目でもご紹介しますが、放置すると怖いので
全部とはいかないまでも、同じ起動条件なのに別れてるプロセスなど
手をつけやすいところは計画的にマージしましょう。
データが増えてくると・・・
###正体不明のエラーが起きる
自社の何十から数百、時には数千のユーザさんを抱えている
Salesforce Adminさんの管理している環境では日々、様々な問題が起き、
エラーメールが届いたり、ユーザから「何かがおかしい」と問い合わせが届いてきます。
それでもカスタマイズや自社の設定に精通し成長してこられた方であれば
大概なんとか解決できます。
が、俗にいうガバナ制限が、"設定を変更してなくても"発生するので、
そのタイミングは肝を冷やすこともあると思います。
意外とググって見ても出てこないものや、
どうしたらいいか分かりづらいものを２つ挙げてみます。
###事例1 Non-selective query
エラーメール的には、こんな感じでUnkhownなエラーとして出る場合もあるようです。
・An unexpected error occurred. Please include this ErrorId if you contact support: 47489574-54543 (-548403183)
デバッグログなどで丁寧に追っていくと、
これが原因として出てくることがあります。
・System.QueryException: Non-selective query against large object type
これはフローの検索要素などで発生します。
あまり絞り込み条件が効かない曖昧な条件で検索していたりすると、効率がよくないクエリだからダメと怒られてるのですが
カスタムで作ったユニーク値などセレクティブ(例えば３０万件中1件ヒットするなど、十分に絞り込まれる条件)
な検索条件でも発生するので混乱するかもしれません。
検索対象オブジェクトのデータ件数が数十万件に登る場合などの場合は、
絞り込み条件に利用したい項目設定に対して"外部ID"のチェックをつけましょう。
内部的にはデータベースにインデクスという検索高速化を狙いとするものが張られて、
高速化"される場合があり"それによって解消するかもしれません。
(DB,OracleDB的な話になりますが、検索条件によってはインデクスが効かない場合があります)
外部ID項目を使い切ってしまっており、追加できない場合は、サポートに連絡を。
検索条件と、インデクスを貼りたい項目を申請し、承認されると追加出来る場合があります。
###事例2 CPU TimeLimit
Salesforceはみんな(多くの企業)で使うインフラなので、処理が長くなりすぎると打ち切られます。
とはいえ、省略していい処理が見当たらない・・・ということもあります。
プロセスを統合してみる
前述した「1オブジェクトにつき1プロセスにする」なんかは、チェックしたいポイントです。
条件に該当しなくて、処理はしないとしても、
同じオブジェクトのプロセスが20本あれば
「プロセスを呼び出して→判定して→何もせずに終了する」
というステップは必ず20本実行されます。
これもボディブローのように効いてきます。
その他、再評価処理、空更新処理、緩い起動条件の精査
カオスな図にあったように、再評価のフラグをつけたプロセスビルダが動いて
何回も何回も知らずのうちに無駄に処理が回ってる可能性もあり
掛け算で処理ステップ数が増えてるかもしれません。
こういう場合は、プロセスビルダーの統合のほか、
こんな観点で"今出来ること"、を洗って、少しずつでも改善して
エラーの解消を試みるのもいいでしょう。
- 常に起動するような緩い条件のPBはないか？
- 整合性を確実に確保しなければいけない処理はどれか、不要な再帰処理フラグの立っているものはないか？
- 条件が緩く、毎回起動されてしまう上に、同じ項目を同じ値で上書きするだけなど無意味な処理がある(“〜が変更されたら”など、実処理を起こさないように追加できないか？)
データ移行を乗り切る
画面から１レコードの保存で、このエラーが出ることは多くないです。
データ移行など大量レコードをデータローダーで入れる時などによく見るイメージです。
この場合、徹夜を覚悟しながらのエラー対処はつらすぎます。
１件だけ入れて発生しないなら、データローダーのバッチサイズを1にするなどして
ゆっくりデータを入れて解消しないか見ましょう。
それだと拉致があかない、時間が足りないとかであれば
データ移行時はプロセスビルダやフローが動かないようにする、というのも、手です。
プロセスビルダーやフローの起動条件/分岐条件に、
"起動フラグがオンの場合は、実行する”
といった条件を入れておく方法です。
例えばこんな感じです。
プロセスやフローが動いてくれなくなるので、その前提でデータを作って投入する手間はありますが、
少なくとも想定外の動きはしなくなります。
データ移行時はこのフラグをオフにしておくと、プロセスビルダーが動かない、という制御になります。
(フローやプロセスを手で無効化しても良いですが、数が多いと苦行です、再有効化漏れしがち)
前もってやっておく必要があるので、ハマってしまったら
手でプロセスを無効化して、データ正しく入れて、再度有効化して朝を迎える。
この辺りの考慮は、プロセスの統合を考えるあたりで、ついでに実装しておくと良いかもしれません。
その他
ぶっちゃけベースですが、
本当に困った時って、難しくて長ーいデバッグログを解析してエラーを理解する、
という作業が発生してしまい、、結構スキルやシステム的な勘所がいるかもしれません。
もし、PremiereSuccessPlanを契約していると、その中の開発者サポートのサービスで
フローやプロセスの内部のエラー調査についても問い合わせができ、かなり心強いです。
(Premiereに含まれるサービスはかなりあるので、メリット享受してない人はサービス内容を確認してみましょう)
#さいごに
なんだか、書き始めてみたら長くなってしまいました。
起きるトラブルや対処の一部しか書けてないものの、
個人的にホントに困ったり悩んだり対処した部分を書いてみました。
これからローコードと共に歩んでいこうという方の足しになればと思います。
(またネタがあれば溜めていきます)
Salesforceはローコードプラットフォームとしても、とにかく拡張性に富んでいるプロダクトです。
その分、うまく使えた時のリターンは大きいので、めげずに、取り組んでいって欲しいと思います。
Adminの方、お友達レベルのご相談など、TwitterのDMで
カジュアルに頂ければと思います。(こちらも勉強になるので)
実践であまり使われないかもしれませんが
個人的には__"Lightning Object Creator"__なんかも好きな機能です。
https://www.salesforce.com/jp/blog/2019/09/upload-spreadsheets-lightning-object-creator.html
手元のスプレッドを読み込ませて、サクッとデータや画面の素案を構築できる
機能なので
プリセールス段階や、要件定義上流で、粗いけどイメージを見せながら認識合わせ、を
支援してくれるものなので、認識ギャップやロックインなどの不幸を
ローコード技術が生かされることで少しでも減っていくことを願っています。