Heroku Connect 全く分からない - yonet77的な雑記帳

早速ですが、Heroku Connectの活用について色々と悩んでるあたりを、ツラツラと書いてみようと思います。
そんなわけで、何か結論めいたものがあるワケではなく、現在進行中の悩みを整理すべく文章にしてみようという試みです。

（以前、Code[ish] jp で少しお話ししました - yonet77的な雑記帳で書いた内容を、もう少しだけ深掘りしてみようというあたりです）

最近のお悩み(1)

Heroku Postgres --> Salesforce にデータを書き込もうとして、エラーが発生した場合への対応が色々と面倒だな、と感じています。
エラーが発生したことはログに出てくるし、メールで通知してくれるのでエラーの検出自体は問題ないとは思いますが、そこからの復旧は個人的には面倒かな、と。

具体的には、Heroku Postgres側でHeroku Connectが使用しているスキーマに _trigger_log テーブルがあるので、

stateカラムでFAILEDになっているレコードを確認して
可能であればvaluesカラムの内容を変更して
stateをNEWに変更して保存する

参考) Writing Data to Salesforce with Heroku Connect | Heroku Dev Center

とやれば、そのうち連携処理が実行されて、salesforceにデータが書き込まれる...というものですが、まぁ勝手に変更して良いものかどうか。。
おそらくHeroku Postgresに格納されているデータは、Herokuで稼働しているサイトのユーザが書き込んだ場合が多いでしょうから、下手に変更するものではないかな、と。

Heroku Connect のエラーは回避したい

そんなわけで、Heroku Connect様がSalesforceにデータを気持ちよく書き込んで頂きたい...と思うので、なんとかエラーを回避したいと思います。
Salesforceへのデータ書き込みエラーで思いつくあたりとしては

入力規則によるエラー
書き込み先のオブジェクトで、Apexトリガ ( or Flow) によるエラー
選択リスト値で、値セット以外の値を指定することによるエラー

などがあると思います。
今回、こんな構成を前提にツラツラと書いてみたいと思います。

f:id:yonet77:20201212215713p:plain

「1.」への対応

連携するオブジェクトには入力規則をつけなくても良いと思いますので、入力規則は解除することで回避したいところです。

「2.」への対応

Apexトリガ、Flowによるエラーが発生しても、エラー内容をどこかに通知する / エラー内容を永続化しておくといったことで、とりあえずエラーはやり過ごすことで回避したいと思います。

「3.」への対応

選択リスト値の制限を外すことでひとまずエラーは回避できるかな、とは思います。あるいは、選択リスト値は使わない、など。

さらに

エラー内容がサイト上でも確認できれば、ユーザに適切に修正してもらうことも可能かな、と思います。

まぁ、そもそもサイトから入力したデータに対して、既に稼働している業務用のオブジェクトと同じ入力規則を適用しなくても良い気もしますね。サイトから入力されたデータを識別するための項目を定義しておいて、その項目をみながら入力規則をスキップする、という運用もアリかもしれません。

兎にも角にも、サイトから入力されたデータは、なるべくそのままSalesforceの公開用オブジェクトまでサクッと連携されて、その後の処理でエラーがあれば、Salesforce内で修正するか、サイトから修正してもらうなどして、Postgresをイジる等ということがないようにしたいものです。（面倒だから）

最近のお悩み(2)

(1)からの続きで。
業務用のオブジェクトで、色々と選択リスト値が定義されているとします。
Herokuで公開しているサイトからもデータを入力する場合は、選択リスト値と同様、コンボボックスで定義したいでしょう。

一方で、業務用のオブジェクトの選択リスト値のAPI値 / ラベルともに日本語で定義されていることも多いでしょう。そんな場合の対応として

公開用のオブジェクトでも、同じ内容で選択リスト値を定義する。
- 選択リスト値のAPI / ラベルのセットは、（何らかの方法で）サイト側にも連携しておく。
- ※選択リスト値の組合せを1レコードにしたカスタムオブジェクト（マスタデータのようなもの）を定義して、それをHeroku Connectで連携して利用する、など...
公開用のオブジェクトには、APIとラベル用のテキストフィールドを用意する。（選択リスト値で定義しない）
- 選択リスト値のAPI / ラベルのセットは、上と同様サイト側にも連携しておく。

「1.」について

APIとラベルがそれぞれ日本語の場合、サイト側で利用するにあたってはAPI値は半角英数字だけで定義したくなるのをどうすべきか...。
そのAPI値を使って何か検索処理かけたりとか、Heroku App内で色々使いまわすとかなると、日本語のままだとエンコードが必要になるとか~~（かつてIEだと日本語が入るとうまく処理できないとか）~~不利なことも出てきそうなので、できたら英数字にしたいなと考えたりします。

そうなると、サイト側でもつ定義と、最終的にSalesforceの業務用オブジェクトでもつ定義の不一致を、どっかで吸収する必要がでてきます。

Heroku ConnectでHeroku Postgresと公開用のカスタムオブジェクトは同期していることを考えると、公開用オブジェクトと業務用のオブジェクトの間で、頑張って吸収する感じになりそうですね。
そして、2つの定義を変換するための変換テーブルみたいなものを、どっかに用意しておかないといけないのかな、と。

f:id:yonet77:20201212220748p:plain

「2.」について

いっそのこと、公開用のオブジェクトにはAPI値とラベル値をテキストフィールドとして定義してはどうか？という話です。
「1.」では、結局Heroku Postgresに適当な値が入ると、Heroku Connectでエラーが発生しかねないので、何でも受け付けるようにしてはどうか？という具合ですね。

このパターンにしても、「1.」と同様にSalesforce内での変換処理や、Heroku側でコンボボックスに設定するkeyとvalueの組合せのマスタを連携しておく必要があるので、「1.」と大差ない気がしてきますが、この変換処理とサイトへのマスタ連携は、なかなか厄介な感じがします。

一旦構築した直後は良いと思いますが、その後にSalesforce担当者が業務用のオブジェクトの選択リスト値に項目を追加するなどの操作を行った場合、それに追従する必要があります。
自動追従できなくとも、不整合があることを検知して通知する仕組みが必要になります。（日次でチェック用の処理を実行させる...？）