マイクロソフトナレッジナゲッツの新しいエピソードへようこそ 司会のミロピーターズですさてこんな状況を想像してみてください あなたはビジネスセントラルを使っていて小さな変更が一つ必要になりました例えば顧客レコードへの項目追加承認ステップの変更 あるいは注文を転記する前のチェックルールの追加などですところが誰かがある拡張機能やテーブルページコードユニットといった話を始めると その小さな要望がいきなり難解な専門用語のように聞こえてきます確かに言語ではありますがそんなに不思議なものとして捉える必要はありません ビジネスセントラルをオフィスビルだと考えてみてくださいある言語を使えば開発者は建物そのものに穴を開けることなく 新しい部屋やホームルールを追加するための指示を出せるのです今日の知識の種ナゲットはこれです このエピソードの終わりにはある開発の意味拡張機能が存在する理由そしてカスタム作業がどのようにビジネスセントラルに組み込まれるのかがわかるはずです なぜ企業がビジネスセントラルをカスタマイズするのかビジネスセントラルはバラバラのスプレッドシートやツールではなく財務顧客 受注在庫請求といった日々の業務を一つの連携システムですでに扱っています多くの企業にとって標準の設定で仕事のほとんどはカバーできます しかしここが重要な点です同じやり方で仕事をしている企業は2つとしてありません例えば他の企業では使わないバッジ詳細情報が必要な食品卸売業 請求書発行前に特別な承認プロセスを必要とするサービス業割引のために報酬レベルを設定したい小売業者 独自の文言項目や内部ルールを含むフォームを必要とする会社などです企業はたった一つの項目が足りないという理由で業務方法を変えることはしません またあらゆる小さな要望がシステム全体へのリスクを伴う変更になることも避けたいはずですかつてはそれが大きな問題でした 古いシステムでは開発者が元のコードを開き直接編集していましたそれは次のアップデートが来るまでは機能していました しかしマイクロソフトの新しいバージョンと自社の独自変更が混在してしまいアップデートを適用する前に誰かがすべてを統合調整しなければなりませんでした オフィスで入居者が計画もなしに壁の中に勝手に新しいケーブルを通している様子を想像してみてくださいしばらくは動きますが建物が修理を必要とするとき どのケーブルが誰のものか誰もわからなくなりますビジネスセントラルは異なるアプローチをとっています 標準アプリケーションを書き換えるのではなく開発者は標準機能に接続する別のアドオンを作成します標準部分はそのままに自社の変更は横においてシステム内のサポートされた接点を通じて 機能させるのですこの分離はアップデート時に重要になりますマイクロソフトは建物の標準部分を更新し独自の作業は独自のスペースに止まるからです テストや修正は依然として必要ですがそれはソフトウェアの変更にはつきものですしかし開発者がマイクロソフトの元のコードの中にあるすべての変更をコピーしてやり直す必要はもうないの ですでは企業は実際に何をカスタマイズするのでしょうか カスタマイズはデータを追加します標準システムでは保存できない配送指示内部リスクスコア 会員ランク外部システムへのリンクなどがその例ですまたスタッフがタスクを正しい順序で進められるようガイドする画面も追加します さらに必要な書類が不足している場合に注文を止めるようなルールを強制することもできますカスタム作業は手作業を減らすためにも役立ちます スタッフが毎週金曜日にビジネスセントラルから別のツールへ顧客データをコピーし手作業で条件を確認してマネージャーに報告書を送っていると想像してください 適切に構築された変更であればその情報をビジネスセントラル内に保持し一貫したルールを適用しスタッフの日々の業務に合うボタンやページを提供できます ここである誤解を解いておきましょうすべてをカスタマイズする必要はありません 標準のビジネスセントラルにはすでに多くのプロセスが組み込まれています古いシステムと見た目が違うという理由だけで変更を行うと後で余計な作業が発生します つまり優れたカスタム作業は明確なビジネス上の理由から始まります人々はどのような問題を抱えているのでしょうか 代わりに何が起こるべきなのでしょうかそして標準製品でそれは実現できないのでしょうか標準製品でそのニーズを満たせない場合あるが登場します あるはビジネスセントラル自体に焦点を当てデータベースレベルでレコードを読み取り追加変更しつつページやレポートなどアプリケーションの各部での動作を制御します また値の計算やデータの移動を行いプロセス全体でルールに違反した際にはメッセージを表示します一つの言語としては多くの役割を担っていますがあるはあらゆる種類のソフトウェアに対応する汎用ツールではありません 一般公開のショッピングサイトやモバイルゲームスタンドアロンのデスクトップアプリの構築にこれを選ぶことはないでしょう あるはビジネスセントラル内のデータと動作を調整し会社の運営方法にシステムを適合させるという一つの目的のために存在します そしてそれこそが次に見ていく内容ですあると拡張機能安全なアドオンモデルあるはアプリケーションランゲージの略です これはビジネスセントラルのためのマイクロソフトのプログラミング言語であり開発者が新しいビジネス機能を構築したり既存のシステム動作を変更したりするための構造化された手段を提供します しかし拡張機能エクステンションという言葉もあると同じくらい重要です拡張機能とはビジネスセントラルにインストールできる独立したアプリのことです これは会社のカスタム作業を保持しつつ標準のビジネスセントラルアプリケーション自体には手を加えませんハンドブックを書き直すのではなく承認されたページを書き足すようなものだと考えてください そう元のルールを消去することなくそれに従うページを追加するのですこれは技術的な詳細に聞こえるかもしれませんがカスタム作業が長期的にどう管理される かに大きな影響を与えます会社に特別なチーム用の新しいオフィスルームが必要になったと想像してください 従来のアプローチであればメインビルの壁を壊して構造そのものを変更しなければなりませんでした目先のニーズは満たせるかもしれませんが元の建物と設計図が一致しなくなるため 将来の修復作業は悪夢のようなものとなります拡張機能エクステンションは仕組みが異なります建物にはあらかじめドアやコンセントそしてスペースを追加するためのルールが備わっています 承認された接続口を通じて新しい部屋を増築するのですその部屋は会社のものですがメインの建物はすべての壁を壊すことなくメンテナンスを続けることができますそれこそがビジネスセントラルの拡張機能の仕組みです 基本アプリケーションにはマイクロソフトが提供する標準機能が含まれています拡張機能を使えば独自のフィールド画面ボタンルールレポートさらには他システムへのリンクを追加できます 特定のビジネスアクションに反応させることも可能ですがそれは標準アプリケーションへのサポートされた接続方法を通じて行われますつまり境界線が組み込まれているのですそれは良いことです 境界線がなければ小さなカスタマイズの要望が触れてはいけない領域の深部にまで及ぶ可能性があります拡張機能を使えば開発者は明確なオブジェクトタイプと定義された接続ポイントで作業できるため 後で他の人がコードを読む際にも理解しやすくなりますこのアプローチはクラウド版のビジネスセントラルにも完璧に適合します マイクロソフトは定期的にサービスを更新しています更新後には特に製品の変更箇所に依存している場合企業は拡張機能のテストを行う必要があります ソフトウェアであってもメンテナンスの手間がなくなることはありませんしかしカスタムコードを分離しておくことで 更新の度に以前の修正を大規模に作り直す必要性を減らすことができます古いダイナミクスナビシステムの話の中で CRという言葉を耳にすることがあるかもしれませんCRは開発者がオリジナルのアプリケーションオブジェクトを直接変更することが多かった 以前の開発モデルから生まれたものです多くの企業がその方法で長年システムを運用してきましたが カスタム作業が標準コードと密接に結びついていたため 更新には多くの比較と修正作業が必要でしたあるへの意向によりビジネスセントラルはアプリベースの開発へと進化しました だからといって全ての拡張機能が大規模で複雑なわけではありませんある拡張機能は顧客レコードにフィールドを一つ追加し 使い慣れた画面に表示するだけかもしれません別の拡張機能は独自のレコードプロセスページレポートを備えた 特定の業種向けの完全なソリューションかもしれませんどちらも同じ基本理念に基づいています カスタムアプリはビジネスセントラルを書き換えて隠すのではなくその隣で共存します複数の拡張機能を同時にインストールすることも可能です 例えばソフトウェアパートナーの給与計算用拡張機能配送用拡張機能そしてその会社独自のルールを定めた小さな内部用拡張機能などを組み合わせて利用できますビジネスセントラルはプラットフォームのルールに従い 競合しない限りそれらを同じシステムとして統合して動作させますつまりあるは単なるコードを書く手段ではありません それは開発者がこれらのアドオンアプリを作成するために使う言語であり拡張機能はそれらの変更をビジネスセントラルに反映させるためのコンテナなのですこのモデルにより企業は標準的な製品の識別しやすさと保守の容易さを維持しながらシステムを調整できるようになりますそれではこれらの拡張機能の一つを開いてその中にあるビルディングブロックを見てみましょう ある拡張機能内における主要なあるビルディングブロックです開発者はオブジェクトを使用して作業を行います オブジェクトとは情報の保存画面の表示ルールの実行ドキュメントの作成といった明確な役割を持つ名前の付けられたアプリの一部ですそれらの役割を個別に理解できるようになればあるは単なるコードの塊ではなくなります まずはビジネス情報が保存される場所から始めましょうテーブルはビジネスセントラルでデータを格納します テーブルとは特定の種類のレコードを保管するためのデジタルキャビネットのようなものだと考えてください一つのキャビネットには顧客が別のキャビネットには品目がさらに別のキャビネットには販売注文が保管されるかもしれません 各レコードはそのキャビネット内の一つのファイルに相当します顧客テーブルには各顧客につき一つのレコードが含まれます金目テーブルには各製品につき一つのレコードが含まれます 標準のビジネスセントラルにはない情報が会社で必要な場合拡張機能を使用して独自のテーブルを作成できます例えば報酬レベル危機点検プロジェクト承認などのテーブルです フィールドは各レコード内にあるラベル付けされたスペースです顧客テーブルにはそれらの詳細を格納するフィールドがあるため顧客レコードには名前 住所支払い条件電話番号を含めることができますフィールドにはテキスト日付金額はいいえの回答または固定リストからの選択肢を格納できます フィールドは別のレコードを参照することもできます例えば顧客レコードに報酬 id フィールドを含めることができます担当者は任意のテキストを入力する代わりに別の報酬テーブルから報酬レベルを選択します このリンクにより全員が同じ基地のリストから選択するためデータがクリーンに持たれますつまりテーブルが事実を保持するということです では人はどのようにしてその事実を確認し扱うのでしょうかページですページはビジネスセントラルで開く画面のことです 顧客カードは一つのページです販売注文の一覧も一つのページですページはユーザーが何を表示入力検索操作できるかを制御します 異なる作業にはそれぞれに適したページがありますカードページは一つの顧客や一つの品目など一度に一つのレコードに焦点を当てますリストページは多くのレコードを列で表示するためスキャンフィルタリング素早い検索が必要な場合に適しています ワークシートページは複数の行の情報をまとめて入力または処理する作業をサポートしますテーブルが情報を保存しますページがそれをユーザーの前に提示します この分離は有益ですなぜならデータが存在する場所を変えずに画面を変更したり異なるチームが同じレコードの異なるビューを必要とする場合に複数のページで同じテーブルを再利用できるからです ではデータがすでに標準のビジネスセントラルレコードにある場合はどうすれば良いでしょうか通常フィールドが一つ足りないという理由だけで顧客テーブルを置き換えるようなことはしません その場合はテーブルエクステンションを使用しますテーブルエクステンションは既存の顧客テーブルにフィールドを追加します 標準の顧客レコードは元の場所に留まりエクステンションが標準フィールドの横に会社固有の詳細情報を追加しますそれは報酬IDや配送メモアカウントマネージャーあるいはビジネスの他の部分と接続するフィールドなどかもしれません しかしテーブルにフィールドを追加したからといってそれが自動的に画面に表示されるわけではありませんそのためにはページエクステンションを使用します ページエクステンションは既存のページにフィールドグループまたはアクションを追加します顧客を確認しながらスタッフが報酬レベルを選択する必要がある場合 ページエクステンションを使えばスタッフが普段作業している顧客カード上に報酬IDフィールドを配置できますこれにより操作感を損なわずに済みます 簡単な詳細情報を入力するために別のカスタム画面へユーザーを誘導するのではなく使い慣れたページにその情報を追加できますページエクステンションはタスクを開始するためのアクション つまりボタンやメニューコマンドを追加することもできます例えば顧客カードに報酬リストを開くためのアクションを追加するといった具合です 画面の裏側ではビジネスルールを管理する場所が必要になりますその場所としてよく使われるのがコードユニットです コードユニットには特定の作業を行う名前付きのコードブロックであるあるプロシージャが含まれていますページやレポートその他のプロセスから依頼があった際にタスクを処理するバックオフィスチームのようなものだと考えてください報酬レベルによって顧客に適用される割引が決まると仮定します その割引計算は顧客カードページ自体ではなくコードユニットに配置すべきですそうすれば販売プロセスやレポート将来作成するページで同じルールをあちこちにコピーすることなく利用できますルールは一つ管理場所も一つにするのが原則です ビジネスセントラルには他にも様々な業務に対応するオブジェクトタイプが含まれていますレポートはデータを収集し請求書や販売レポートのようなドキュメントやレイアウトで提示しますクエリは特定の期間中にどの顧客が特定の商品を注文したかといったデータに対する絞り込まれた質問を行います 例えばxmlポートは他のシステムと情報をやり取りする必要がある場合などデータを構造化された形式で取り込んだり送信したりするのに役立ちますこれらの要素を組み合わせれば小規模な顧客報酬エクステンションを構築できます 報酬テーブルには各レベルとその割引率が保存されます報酬ページではスタッフがそれらのレベルを管理できます 顧客テーブルエクステンションで各顧客に報酬IDを追加し顧客カードページエクステンションでそれを表示させますページアクションでリワードリストを開きコードユニットで割引ルールを計算します 各オブジェクトがジョブの一部を処理しますこれにより6ヶ月後にビジネスルールが変更された場合でも拡張機能の読み取りテスト変更が容易になります しかしビジネスルールは注文の転記時などまさに適切なタイミングで実行される必要がありますそこでトリガーとイベントの出番ですイベントトリガーそしてビジネスルール さて顧客リワードフィールドを追加しましたね素晴らしいここからが本題ですビジネスセントラルはいつそのフィールドを使用すべきでしょうか 売上注文を転記しようとしている場面を想像してくださいシステムが最終的なエントリーを作成する前に追加のチェックを行いたいとします 例えば割引が適用される前に顧客が承認済みリワードレベルを持っている必要があるかもしれませんあるいは注文を進める前に必要な配送ドキュメントが存在しなければならないかもしれません 適切なタイミングでチェックを行いたいもののたった一つのルールを追加するために販売転記プロセス全体を自分の拡張機能にコピーしたくはありませんよねそのプロセスは裏側ですでに多くのことを処理しています コピーしてしまうと将来のすべての変更を維持するために拡張機能を更新し続ける必要が出てきますそれは理想的ではありませんそこであるは開発者がコードを実行するためのいくつかの方法を提供しています どれを選ぶかは何を実現する必要があるかによりますまずはトリガーですトリガーとはあるオブジェクト内のコードを実行できる名前付きの場所です 誰かがテーブルフィールドの値を変更するとトリガーがコードを発火させますページが開いたり閉じたりする際にもトリガーがコードを発火させます レポートクエリ xmlポートテーブル拡張機能a o これらすべてに開発者がルールを追加できる場所があります 顧客のリワード id フィールドを例にとってみましょうユーザーがリワードレベルを選択すると検証トリガーを実行できます コードがチェックを行います顧客はブロックされていますかリワードレベルは存在しますか他のフィールドを更新する必要がありますか チェックは値が変更されたその瞬間に実行され後でミスが発覚するようなことはありませんトリガーはルールがそのオブジェクトに密接に関連している場合にうまく機能します しかしビジネスセントラルではイベントも使用されます

あるいはプロセスが完了したといったことを通知します あなたの拡張機能はその通知をリッスンできますリッスンするコードはイベントサブスクライバーと呼ばれますそれは特定の名前付きイベントを待ち受けます ビジネスセントラルがそのイベントを発生させるとサブスクライバーが独自のプロシージャを実行します標準プロセスはそのまま維持されます 例えばビジネスセントラルが売上注文の転記を開始する際続行する前にイベントを発生させます報酬拡張機能がその通知を受け取ります 顧客の報酬IDと割引ルールを確認しますその後処理を続行させるか明確なメッセージを表示して停止させます標準の転記処理は依然としてビジネスセントラルが担います 拡張機能はその接続ポイントで独自の会社ルールを追加するだけですオンビフォーやオンアフターといったイベント名をよく耳にするでしょう オンビフォーはアクションが完了する前にコードが実行されることを意味しますこれは次のステップを阻止するためのチェックに最適です 条件が満たされない場合に販売オーダーを停止するようなケースですアフターはアクションがすでに発生したことを意味します その結果に対して対応できます関連レコードの作成メモの更新あるいは別の作業の開始などです 名前がタイミングを示しておりそのタイミングが重要です転記後に実行されるルールでは転記を阻止することはできません 逆に早すぎるルールでは必要なデータが揃っていない可能性がありますそのため開発者はビジネスルールが何をいつ行うべきかに基づいてイベントを選択します コードはアクションから開始することもできますユーザーが報酬ステータスの確認ボタンをクリックするとそのアクションがプロシージャーを呼び出します またあるオブジェクトが変数を介して別のオブジェクトを呼び出すときにコードが実行されることもあります難しそうに聞こえますが単純なことです 拡張機能のある部分が別の部分に作業の実行を依頼するのですその際に役立つのが変数です変数はコードの実行中に値を保持する名前付きの場所です 数値テキスト日付あるいは現在の顧客のようなビジネスセントラルのレコードでも構いませんあるでは var を使ってこれらを宣言します 例えば報酬プロシージャはカスタマーという変数を使って現在の顧客レコードを保持しますディスカウントパーセントという別の変数は割引率を保持します これらは永続的なレコードではありませんあくまでそのコードを実行するための作業用の値ですコードの配置場所について説明します ルールが複数の場所で使用される可能性がある場合はコードユニットに配置しますそうすれば顧客カード販売プロセスレポートのすべてが同じ割引プロシージャを呼び出せます これによりよくある問題を回避できますある画面では10%割引別の画面では5%割引となり どれが正しいルールかわからなくなる問題です共有のビジネスルールを一つのコードユニットにまとめることで判断基準を一本化できます つまりトリガーはオブジェクトに近い場所でのルールを処理しますイベントはビジネスセントラルのプロセスに対して拡張機能が反応できるようにします コードユニットは共有ロジックをまとめて管理しますこれらの要素がつながった後次に問題となるのは開発者はどこであるコードを書き テストし検査するのかということですあるの開発は通常ブスコードとも呼ばれるビジュアルスタジオコードで行われます あるファイルを記述するためのワークスペースですエクステンションを整理された状態に保ちます 問題の発見を助け完成したアプリをテスト用のビジネスセントラル環境へ送信しますしかしブスコード単体では汎用的なコードエディターにすぎません マイクロソフトが提供するある言語エクステンションが必要ですそのエクステンションによりブスコードはビジネスセントラルの仕組みを理解します 入力中にオブジェクト名を提案してくれます公開前にエラーを指摘してくれます フィールドやプロシージャの参照を助けますそしてプロジェクトをビジネスセントラル環境に接続します これにより多くの推測作業が不要になります新しいあるプロジェクトを開始する際はブスコード内である5コマンドを実行しますプロジェクトの基本フォルダーとエクステンション名発行者バージョン 使用するビジネスセントラル環境を指定する設定ファイルが作成されますそのプロジェクトフォルダーをエクステンションの作業台と考えてください すべてのあるファイルはそこに格納されますあるファイルにはテーブル別のファイルにはページエクステンション コードユニットには専用のファイルといった具合ですこうすれば誰かがプロジェクトを開いた時巨大なドキュメントをスクロールすることなく適切なパーツを見つけることができますコードがテスト可能な状態になるとブスコードはそれをアプリパッケージにコンパイルします それがエクステンションのインストール可能なバージョンですビジネスセントラルはそのパッケージを読み込みエクステンションを環境に追加します フィールドの不足やスペルミスなどアプリのビルドを妨げる問題があればパッケージがビジネスセントラルに到達する前にブスコードが通知します テストはまずサンドボックス環境で行う必要がありますサンドボックスとは別のビジネスセントラル環境であり 実際の業務に影響を与えることなく変更を試すことができますエクステンションを公開しページを開いて変更を確認し テストレコードを入力してルールが期待通りに動作するかを確認しますその分離が重要なのです スタッフが業務を行っている最中に新しい検証ルールによって受注電票がブロックされるような事態は避けなければなりませんサンドボックスなら本番のレコードに影響を与えることなく失敗したり テストデータを削除したりコードを変更して再公開したりできますコードは動いていても結果が正しくない場合があります そんな時に役立つのがデバッグです コードにブレークポイントを配置して処理を開始すると実行中にエクステンションが一時停止します停止中に現在の顧客や選択された報酬レベル プロシージャが計算した割引率などの値を調査できますなぜルールが失敗したのかを推測する代わりにコードが何を受け取ったのかを正確に確認できます 開発チームはgitを使用して作業の履歴を管理することも一般的ですgitはプロジェクトファイルに対する時間の経過に伴う変更を記録します 誰かがルールを変更して問題が発生した場合チームはバージョンを比較して変更点を確認し必要に応じて元に戻すことができます また複数の開発者が同じ拡張機能に取り組む際にも役立ちます初心者の場合小さく始めるのが最善の道です まずビジネスセントラルの操作に慣れてから一つのテーブルと一つのページを作成してみましょうその後標準ページを拡張して簡単なビジネスルールを追加し イベントやインストールデータがプロジェクトにどう組み込まれるかを学びます次にそれらの要素を実際の業務で使える小さなアドオンを通じてつなげてみましょう 簡単な例として顧客特典アドオンを構築します実際のある拡張機能とはどのようなものでしょうか 簡単な例に飛び込んでみましょう会社で顧客の特典レベルを設定しそれぞれに割引を適用したいと想像してください まずは特典テーブルを作成することから始めます各ファイルにID説明割引率を保持するデジタルキャビネットのようなものだと考えてください 例えばゴールドランクなら10%オフといった具合ですスタッフが技術的なツールに触れることなくそれらのレベルを管理できるようにする必要があります そこで全レベルを表示する特典リストページと編集や作成を行う特典カードページの2つを追加します開発環境を開かなくてもスタッフは新しいレベルの追加やパーセンテージの調整 内容の確認を行うことができます次に顧客テーブルを拡張して特典IDという新しいフィールドを追加します そのフィールドは各顧客を一つの特典レコードに紐付けスタッフが顧客情報を管理する顧客カードページにそのフィールドを配置しますさらに特典アクションを追加し同じカードから直接特典リストを開けるようにします 割引ルール自体はコードユニットの中に配置されます他のプロセスで顧客の割引が必要な場合ページごとに何度も計算するのではなくそのコードユニットを呼び出します これが効率的ですインストールコードユニットは拡張機能が初めてインストールされた時に初期特典レベルを追加します そしてイベントサブスクライバーが販売プロセス中に選択された特典レベルをチェックし適切なタイミングで会社のルールを適用します 小さな拡張機能ですがその中身に注目してくださいデータテーブルユーザー画面ナビゲーションアクション設定ロジックそしてビジネスルールがすべて連携して機能しています それこそがあるの真の力ですさて結論としてある開発の出発点についてです まとめると以下のようになりますある開発を使えばコアアプリケーションに触れることなく会社が必要とする特定の機能を ビジネスセントラルに追加できますすべてを一度に構築する必要はありません まずは一つのフィールド一つのページ拡張そして一つの明確なルールから始めましょうそれがあなたの最初の構成要素となります 今回の知識のヒントが役立ちましたらお気に入りのポッドキャストプラットフォームで登録しビジネスセントラルの開発を始めたばかりの方と共有してください 次回もまたパズルのピースを一つ埋めていきましょうマーコピーターズがお届けした m 365 fm のマイクロソフト知識のヒントでした