Castroが寄稿した記事を抄訳したものです。こちらからご覧いただけます。開発を扱う部署は複数存在しますか?Salesforceの担当部門で行うカスタマイズが有用な機能を開発し、他方、そのカスタマイズが会社の事業目標や技術戦略と矛盾しないようにするためには、アーキテクチャレビューボード(ARB)の設置は検討に値する選択肢です。ARBはさらに、本質的に異なるワークストリームが複数存在する場合、方向性の共有やコラボレーションを促進する一方、機能の衝突や重複を避けるための中継地としても機能します。蓄積させることにもなりかねません。要するに、ARBは社内で現在実装中の機能を見える化するための効果的な方法となりうるのです。実際のARB運用は簡単な話ではありません。以下によくある問題を掲げます。未処理の案件が多いとARBが決済用の“ゴム印”のようになってしまう。IT部門と事業部門が同じ目標を共有できないとARBが衝突を引き起こしてしまう。ARBの審査案件で未処理が発生すれば、結果的に、開発サイクルの中では実装するにはもはや遅すぎる提言が行われることになる。多くの場合、これは技術的負債の増加につながる(そして返済はほぼ期待できない)。開発部門が持ち出さない限り、ARBは審査すべき案件が存在することさえ知らずにいる。上述の課題を克服するためにARBができることを以下に提案します。ARBはまず、審査の指針と開発標準を定義、公開し、開発部門がARBの承認を要する案件とそうでない案件とを判別できるようにする必要があります。指針や標準の定め方は組織によって異なり、変容する組織のニーズに適応するため、継続的に見直さなければなりません。コンポーネント)をすべて審査の対象とするかもしれません。この組織が「ピクセルパーフェクト」のコミュニティを新しく作る場合、SLDS、Bootstrap、SlickGridを活用したコミュニティUIに対応するために標準を更新することもあるでしょう。一般的に、ARBはインテグレーション案件、データサイズの大きいオブジェクトに触る案件、脆弱なコード、複雑なコード、古いコード、基幹業務の遂行に不可欠なビジネスプロセスの審査をしたがるものです。ARBの審査を必要とする案件(例えば、VFページ、Apexクラス、Apexトリガー、検証ルールなど)の抽出は自動化すべきです。新規のファイルや変更したファイルを特定するにはソースコントロールが有効でしょう。Artifactカスタムオブジェクトに抽出したことがあります。この方法で抽出する案件は数が多すぎて個別に審査できない場合があります。Groupカスタムオブジェクトを作成しました。Groupに焦点を当てて審査をすれば、例えば2つのVFページ、14のApexクラス、2つのトリガーを伴うカスタマイズを一気に処理することができます。Until”で承認年月日を設定し、それまで無視してよい案件を指定します。Artifactに変更をUPSERTするプロセスは承認済みの案件と無視してよい期日内の案件を無視します。その他の案件にはARBによる審査が必要な案件としてフラグが立ちます。(「カスタマイズを監視してSalesforce組織を保護する方法」については次回のブログでご紹介します。)ARBの規模は意志決定の権限を有する必要最低限の人数に制限するのが望ましいと考えます。事業部門とIT部門の代表者には必ず参加してもらいましょう。事業への影響を正しく評価せずに、カスタム開発に関する意思決定を行うのは困難です。ARBの委員が6人から8人を超える場合は、審査委員会を(地域別あるいは事業部門別に)分けて、他の地域や部門に影響しない案件の審査を任せ、全体を統括するARBが連絡役を担うことも検討しましょう。地域別・部門別のARBは審査の指針と開発標準を整備するため、定期的に集合するようにしましょう。ARBが行う個々の意志決定は指針に反映させることが重要です。将来の開発部門がARBの承認を得られるタイプの案件とそうでない案件を理解できるようにするためです。望ましくない前例を作らないことも重要です。しても必要な機能の開発を認めるために譲歩を要するなら、例外を許した文脈や理由、あるいは承認に際して設けた条件があるならその条件も含め、これらを周知させなければなりません。ポイントツーポイントのインテグレーションを、今現在利用できるミドルウェアがないという理由で承認するとします。あれば、これはミドルウェアの評価と調達サイクルが完了し次第、修正を要する「技術的負債」として承認すべきでしょう。以下に効果的なARBを要約します。開発部門が参照するための指針と開発標準を公開し、定期的に修正する。ARBのプロセスを自動化し、その無効化を防ぐ。案件のグループ化や絞り込みにより、審査する案件数を抑制する。事業部門とIT部門から適任者を任用し、必要最低限の人数で構成する。皆さんのARB構築がうまくいくように祈ります。引き続き、ARBに関する投稿にご期待ください。ConnectでForce.com上に作ったカスタムオブジェクトの内容を表示してみるこんにちは。Connectを使ってHeroku上に構築したWebアプリケーションに表示してみます。Singhが寄稿した記事を抄訳したものです。こちらからご覧いただけます。入門編ブログをシリーズに渡ってお届けします。開発の基本から簡単な応用テクニックまでを網羅します。Platform」についてご紹介します。主導のシステム連携をサポートするための幅広い機能が単一のプラットフォーム上で提供されています。デプロイ作業について説明します。実装について説明しました。デプロイ作業について説明します。変換例を紹介しようと思います。変数や関数の利用、典型的な変換パターンを例を交えて説明します。使ったブラウザ環境でのMuleアプリケーションの開発についてご紹介します。Muleアプリケーションを作成することに比べて、とても手軽にアプリケーションを開発できます。して提供されている単体テスト用のフレームワークです。同じようにテストスイートを実行することで単体テストを自動実行できます。開発におけるテストについて考えていきます。つのレベルの検証を実施すべきと考えます。実装したらすぐに運用開始できるというものではありません。ポリシー設定についてご紹介します。API管理は標準のポリシーの組み合わせで幅広い要件をカバーできますが、場合によっては既存機能の拡張や新機能の定義が必要になります。今回は、「カスタムポリシー」の開発手順についてご紹介します。リソースのバージョン」)を管理する必要があります。バージョン管理についてご紹介します。アプリケーションの実装方法について紹介しようと思います。アプリケーションの実装方法を引き続きご紹介します。ついて、その特長と使い方をご紹介します。ComponentsがSrping'19から提供されることになりました。Componentsが登場してきた背景とその特長について説明します。Componentsの基本的な構成(メタデータ、html、JavaScript)や実装のルールについて説明します。JavaScriptコードなどはAuraコンポーネント時代からかなり変更された要素ではありますが、より簡潔にコードが書けるように進化しているという印象を受けました。今回は簡単なサンプル・コンポーネントを通して、LWCの基本的な実装方法とSalesforceサーバーからのデータの取得方法を見ていくことにします。Serviceというノンコーディングでサーバーからデータを取得できる便利な方法が導入されており、いくつかの方法でサーバーデータを取得できます。本稿ではその特長と使い分けについて解説してみます。CLIを使って行います。今回はこのCLI(コマンドライン・インターフェース)にスポットを当ててみたいと思います。CLIは従来はAPIでのみ提供されていたSalesforceサーバーに対する様々な機能をコマンド形式で実行できる環境であり、Winter’18で正式にリリースされました。第5回目の今回は応用編ということで、本格的なLWCの実装時に必要となるテクニックをいくつか紹介します。各種資料ENGLISHこのハブをシェアするFacebookTwitterEmailLinkedIn。