WEBVTT 00:00:00.000 --> 00:00:03.880 マイクロソフトナレッジナゲッツの新しいエピソードへようこそ 司会のミロピーターズです 00:00:03.880 --> 00:00:08.940 さてこんな状況を想像してみてください あなたはビジネスセントラルを使っていて小さな変更が一つ必要になりました 00:00:08.940 --> 00:00:14.580 例えば顧客レコードへの項目追加承認ステップの変更 あるいは注文を転記する前のチェックルールの追加などです 00:00:14.580 --> 00:00:21.500 ところが誰かがある拡張機能やテーブルページコードユニットといった話を始めると その小さな要望がいきなり難解な専門用語のように聞こえてきます 00:00:21.500 --> 00:00:27.020 確かに言語ではありますがそんなに不思議なものとして捉える必要はありません ビジネスセントラルをオフィスビルだと考えてみてください 00:00:27.020 --> 00:00:32.960 ある言語を使えば開発者は建物そのものに穴を開けることなく 新しい部屋やホームルールを追加するための指示を出せるのです 00:00:32.960 --> 00:00:38.700 今日の知識の種ナゲットはこれです このエピソードの終わりにはある開発の意味拡張機能が存在する理由 00:00:38.700 --> 00:00:44.460 そしてカスタム作業がどのようにビジネスセントラルに組み込まれるのかがわかるはずです なぜ企業がビジネスセントラルをカスタマイズするのか 00:00:44.460 --> 00:00:51.760 ビジネスセントラルはバラバラのスプレッドシートやツールではなく財務顧客 受注在庫請求といった日々の業務を一つの連携システムですでに扱っています 00:00:51.760 --> 00:00:58.900 多くの企業にとって標準の設定で仕事のほとんどはカバーできます しかしここが重要な点です同じやり方で仕事をしている企業は2つとしてありません 00:00:58.900 --> 00:01:05.900 例えば他の企業では使わないバッジ詳細情報が必要な食品卸売業 請求書発行前に特別な承認プロセスを必要とするサービス業 00:01:05.900 --> 00:01:12.900 割引のために報酬レベルを設定したい小売業者 独自の文言項目や内部ルールを含むフォームを必要とする会社などです 00:01:12.900 --> 00:01:20.540 企業はたった一つの項目が足りないという理由で業務方法を変えることはしません またあらゆる小さな要望がシステム全体へのリスクを伴う変更になることも避けたいはずです 00:01:20.540 --> 00:01:26.280 かつてはそれが大きな問題でした 古いシステムでは開発者が元のコードを開き直接編集していました 00:01:26.280 --> 00:01:32.940 それは次のアップデートが来るまでは機能していました しかしマイクロソフトの新しいバージョンと自社の独自変更が混在してしまい 00:01:32.940 --> 00:01:41.420 アップデートを適用する前に誰かがすべてを統合調整しなければなりませんでした オフィスで入居者が計画もなしに壁の中に勝手に新しいケーブルを通している様子を想像してみてください 00:01:41.420 --> 00:01:46.380 しばらくは動きますが建物が修理を必要とするとき どのケーブルが誰のものか誰もわからなくなります 00:01:46.380 --> 00:01:53.760 ビジネスセントラルは異なるアプローチをとっています 標準アプリケーションを書き換えるのではなく開発者は標準機能に接続する別のアドオンを作成します 00:01:53.760 --> 00:02:01.520 標準部分はそのままに自社の変更は横においてシステム内のサポートされた接点を通じて 機能させるのですこの分離はアップデート時に重要になります 00:02:01.520 --> 00:02:09.520 マイクロソフトは建物の標準部分を更新し独自の作業は独自のスペースに止まるからです テストや修正は依然として必要ですがそれはソフトウェアの変更にはつきものです 00:02:09.520 --> 00:02:13.940 しかし開発者がマイクロソフトの元のコードの中にあるすべての変更をコピーしてやり直す必要はもうないの です 00:02:13.940 --> 00:02:18.120 では企業は実際に何をカスタマイズするのでしょうか カスタマイズはデータを追加します 00:02:18.120 --> 00:02:24.080 標準システムでは保存できない配送指示内部リスクスコア 会員ランク外部システムへのリンクなどがその例です 00:02:24.080 --> 00:02:31.640 またスタッフがタスクを正しい順序で進められるようガイドする画面も追加します さらに必要な書類が不足している場合に注文を止めるようなルールを強制することもできます 00:02:31.640 --> 00:02:37.860 カスタム作業は手作業を減らすためにも役立ちます スタッフが毎週金曜日にビジネスセントラルから別のツールへ顧客データをコピーし 00:02:37.860 --> 00:02:45.960 手作業で条件を確認してマネージャーに報告書を送っていると想像してください 適切に構築された変更であればその情報をビジネスセントラル内に保持し一貫したルールを適用し 00:02:45.960 --> 00:02:50.060 スタッフの日々の業務に合うボタンやページを提供できます ここである誤解を解いておきましょう 00:02:50.060 --> 00:02:54.840 すべてをカスタマイズする必要はありません 標準のビジネスセントラルにはすでに多くのプロセスが組み込まれています 00:02:54.840 --> 00:03:01.060 古いシステムと見た目が違うという理由だけで変更を行うと後で余計な作業が発生します つまり優れたカスタム作業は明確なビジネス上の理由から始まります 00:03:01.060 --> 00:03:07.360 人々はどのような問題を抱えているのでしょうか 代わりに何が起こるべきなのでしょうかそして標準製品でそれは実現できないのでしょうか 00:03:07.360 --> 00:03:14.840 標準製品でそのニーズを満たせない場合あるが登場します あるはビジネスセントラル自体に焦点を当てデータベースレベルでレコードを読み取り 00:03:14.840 --> 00:03:24.140 追加変更しつつページやレポートなどアプリケーションの各部での動作を制御します また値の計算やデータの移動を行いプロセス全体でルールに違反した際にはメッセージを表示します 00:03:24.140 --> 00:03:31.180 一つの言語としては多くの役割を担っていますがあるはあらゆる種類のソフトウェアに対応する汎用ツールではありません 一般公開のショッピングサイトやモバイルゲーム 00:03:31.180 --> 00:03:40.140 スタンドアロンのデスクトップアプリの構築にこれを選ぶことはないでしょう あるはビジネスセントラル内のデータと動作を調整し会社の運営方法にシステムを適合させるという一つの目的の 00:03:40.140 --> 00:03:46.360 ために存在します そしてそれこそが次に見ていく内容ですあると拡張機能安全なアドオンモデル 00:03:46.360 --> 00:03:53.520 あるはアプリケーションランゲージの略です これはビジネスセントラルのためのマイクロソフトのプログラミング言語であり開発者が新しいビジネス機能を 00:03:53.520 --> 00:04:02.060 構築したり既存のシステム動作を変更したりするための構造化された手段を提供します しかし拡張機能エクステンションという言葉もあると同じくらい重要です拡張機能とはビジネス 00:04:02.060 --> 00:04:08.500 セントラルにインストールできる独立したアプリのことです これは会社のカスタム作業を保持しつつ標準のビジネスセントラルアプリケーション自体には手を加えません 00:04:08.500 --> 00:04:15.220 ハンドブックを書き直すのではなく承認されたページを書き足すようなものだと考えてください そう元のルールを消去することなくそれに従うページを追加するのです 00:04:15.220 --> 00:04:21.720 これは技術的な詳細に聞こえるかもしれませんがカスタム作業が長期的にどう管理される かに大きな影響を与えます会社に特別なチーム用の新しいオフィスルームが必要になったと 00:04:21.720 --> 00:04:26.320 想像してください 従来のアプローチであればメインビルの壁を壊して構造そのものを変更しなければなりませんでした 00:04:26.320 --> 00:04:34.580 目先のニーズは満たせるかもしれませんが元の建物と設計図が一致しなくなるため 将来の修復作業は悪夢のようなものとなります拡張機能エクステンションは仕組みが異なります 00:04:34.580 --> 00:04:45.100 建物にはあらかじめドアやコンセントそしてスペースを追加するためのルールが備わっています 承認された接続口を通じて新しい部屋を増築するのですその部屋は会社のものですがメインの建物はすべての壁を壊すことなくメンテナンスを続けることができます 00:04:45.100 --> 00:04:51.100 それこそがビジネスセントラルの拡張機能の仕組みです 基本アプリケーションにはマイクロソフトが提供する標準機能が含まれています 00:04:51.100 --> 00:05:01.480 拡張機能を使えば独自のフィールド画面ボタンルールレポートさらには他システムへのリンクを追加できます 特定のビジネスアクションに反応させることも可能ですがそれは標準アプリケーションへのサポートされた接続方法を通じて行われます 00:05:01.480 --> 00:05:08.880 つまり境界線が組み込まれているのですそれは良いことです 境界線がなければ小さなカスタマイズの要望が触れてはいけない領域の深部にまで及ぶ可能性があります 00:05:08.880 --> 00:05:16.520 拡張機能を使えば開発者は明確なオブジェクトタイプと定義された接続ポイントで作業できるため 後で他の人がコードを読む際にも理解しやすくなります 00:05:16.520 --> 00:05:22.640 このアプローチはクラウド版のビジネスセントラルにも完璧に適合します マイクロソフトは定期的にサービスを更新しています 00:05:22.640 --> 00:05:30.740 更新後には特に製品の変更箇所に依存している場合企業は拡張機能のテストを行う必要があります ソフトウェアであってもメンテナンスの手間がなくなることはありません 00:05:30.740 --> 00:05:36.380 しかしカスタムコードを分離しておくことで 更新の度に以前の修正を大規模に作り直す必要性を減らすことができます 00:05:36.380 --> 00:05:40.920 古いダイナミクスナビシステムの話の中で CRという言葉を耳にすることがあるかもしれません 00:05:40.920 --> 00:05:46.920 CRは開発者がオリジナルのアプリケーションオブジェクトを直接変更することが多かった 以前の開発モデルから生まれたものです 00:05:46.920 --> 00:05:55.100 多くの企業がその方法で長年システムを運用してきましたが カスタム作業が標準コードと密接に結びついていたため 更新には多くの比較と修正作業が必要でした 00:05:55.100 --> 00:06:01.280 あるへの意向によりビジネスセントラルはアプリベースの開発へと進化しました だからといって全ての拡張機能が大規模で複雑なわけではありません 00:06:01.280 --> 00:06:05.580 ある拡張機能は顧客レコードにフィールドを一つ追加し 使い慣れた画面に表示するだけかもしれません 00:06:05.580 --> 00:06:11.780 別の拡張機能は独自のレコードプロセスページレポートを備えた 特定の業種向けの完全なソリューションかもしれません 00:06:11.780 --> 00:06:17.740 どちらも同じ基本理念に基づいています カスタムアプリはビジネスセントラルを書き換えて隠すのではなくその隣で共存します 00:06:17.740 --> 00:06:28.000 複数の拡張機能を同時にインストールすることも可能です 例えばソフトウェアパートナーの給与計算用拡張機能配送用拡張機能そしてその会社独自のルールを定めた小さな内部用拡張機能などを組み合わせて利用できます 00:06:28.000 --> 00:06:33.680 ビジネスセントラルはプラットフォームのルールに従い 競合しない限りそれらを同じシステムとして統合して動作させます 00:06:33.680 --> 00:06:42.500 つまりあるは単なるコードを書く手段ではありません それは開発者がこれらのアドオンアプリを作成するために使う言語であり拡張機能はそれらの変更をビジネスセントラルに反映させるためのコンテナなのです 00:06:42.500 --> 00:06:47.400 このモデルにより企業は標準的な製品の識別しやすさと保守の容易さを維持しながらシステムを調整できるようになります 00:06:47.400 --> 00:06:54.200 それではこれらの拡張機能の一つを開いてその中にあるビルディングブロックを見てみましょう ある拡張機能内における主要なあるビルディングブロックです 00:06:54.200 --> 00:07:02.900 開発者はオブジェクトを使用して作業を行います オブジェクトとは情報の保存画面の表示ルールの実行ドキュメントの作成といった明確な役割を持つ名前の付けられたアプリの一部です 00:07:02.900 --> 00:07:09.500 それらの役割を個別に理解できるようになればあるは単なるコードの塊ではなくなります まずはビジネス情報が保存される場所から始めましょう 00:07:09.500 --> 00:07:15.020 テーブルはビジネスセントラルでデータを格納します テーブルとは特定の種類のレコードを保管するためのデジタルキャビネットのようなものだと考えてください 00:07:15.020 --> 00:07:24.640 一つのキャビネットには顧客が別のキャビネットには品目がさらに別のキャビネットには販売注文が保管されるかもしれません 各レコードはそのキャビネット内の一つのファイルに相当します顧客テーブルには各顧客につき一つのレコードが含まれます 00:07:24.640 --> 00:07:33.100 金目テーブルには各製品につき一つのレコードが含まれます 標準のビジネスセントラルにはない情報が会社で必要な場合拡張機能を使用して独自のテーブルを作成できます 00:07:33.100 --> 00:07:40.060 例えば報酬レベル危機点検プロジェクト承認などのテーブルです フィールドは各レコード内にあるラベル付けされたスペースです 00:07:40.060 --> 00:07:46.740 顧客テーブルにはそれらの詳細を格納するフィールドがあるため顧客レコードには名前 住所支払い条件電話番号を含めることができます 00:07:46.740 --> 00:07:53.900 フィールドにはテキスト日付金額はいいえの回答または固定リストからの選択肢を格納できます フィールドは別のレコードを参照することもできます 00:07:53.900 --> 00:07:56.860 例えば顧客レコードに報酬 id フィールドを含めることができます 00:07:56.860 --> 00:08:04.320 担当者は任意のテキストを入力する代わりに別の報酬テーブルから報酬レベルを選択します このリンクにより全員が同じ基地のリストから選択するためデータがクリーンに持たれます 00:08:04.320 --> 00:08:08.660 つまりテーブルが事実を保持するということです では人はどのようにしてその事実を確認し扱うのでしょうか 00:08:08.660 --> 00:08:14.820 ページですページはビジネスセントラルで開く画面のことです 顧客カードは一つのページです販売注文の一覧も一つのページです 00:08:14.820 --> 00:08:24.040 ページはユーザーが何を表示入力検索操作できるかを制御します 異なる作業にはそれぞれに適したページがありますカードページは一つの顧客や一つの品目など一度に一つのレコードに焦点を当てます 00:08:24.040 --> 00:08:34.400 リストページは多くのレコードを列で表示するためスキャンフィルタリング素早い検索が必要な場合に適しています ワークシートページは複数の行の情報をまとめて入力または処理する作業をサポートします 00:08:34.400 --> 00:08:44.460 テーブルが情報を保存しますページがそれをユーザーの前に提示します この分離は有益ですなぜならデータが存在する場所を変えずに画面を変更したり異なるチームが同じレコードの異なる 00:08:44.460 --> 00:08:51.480 ビューを必要とする場合に複数のページで同じテーブルを再利用できるからです ではデータがすでに標準のビジネスセントラルレコードにある場合はどうすれば良いでしょうか 00:08:51.480 --> 00:08:57.000 通常フィールドが一つ足りないという理由だけで顧客テーブルを置き換えるようなことはしません その場合はテーブルエクステンションを使用します 00:08:57.000 --> 00:09:05.980 テーブルエクステンションは既存の顧客テーブルにフィールドを追加します 標準の顧客レコードは元の場所に留まりエクステンションが標準フィールドの横に会社固有の詳細情報を追加します 00:09:05.980 --> 00:09:14.600 それは報酬IDや配送メモアカウントマネージャーあるいはビジネスの他の部分と接続するフィールドなどかもしれません しかしテーブルにフィールドを追加したからといってそれが自動的に画面に表示されるわけではありません 00:09:14.600 --> 00:09:20.200 そのためにはページエクステンションを使用します ページエクステンションは既存のページにフィールドグループまたはアクションを追加します 00:09:20.200 --> 00:09:27.580 顧客を確認しながらスタッフが報酬レベルを選択する必要がある場合 ページエクステンションを使えばスタッフが普段作業している顧客カード上に報酬IDフィールドを配置できます 00:09:27.580 --> 00:09:35.720 これにより操作感を損なわずに済みます 簡単な詳細情報を入力するために別のカスタム画面へユーザーを誘導するのではなく使い慣れたページにその情報を追加できます 00:09:35.720 --> 00:09:40.640 ページエクステンションはタスクを開始するためのアクション つまりボタンやメニューコマンドを追加することもできます 00:09:40.640 --> 00:09:47.560 例えば顧客カードに報酬リストを開くためのアクションを追加するといった具合です 画面の裏側ではビジネスルールを管理する場所が必要になります 00:09:47.560 --> 00:09:53.760 その場所としてよく使われるのがコードユニットです コードユニットには特定の作業を行う名前付きのコードブロックであるあるプロシージャが含まれています 00:09:53.760 --> 00:09:59.240 ページやレポートその他のプロセスから依頼があった際にタスクを処理するバックオフィスチームのようなものだと考えてください 00:09:59.240 --> 00:10:07.280 報酬レベルによって顧客に適用される割引が決まると仮定します その割引計算は顧客カードページ自体ではなくコードユニットに配置すべきです 00:10:07.280 --> 00:10:13.020 そうすれば販売プロセスやレポート将来作成するページで同じルールをあちこちにコピーすることなく利用できます 00:10:13.020 --> 00:10:18.840 ルールは一つ管理場所も一つにするのが原則です ビジネスセントラルには他にも様々な業務に対応するオブジェクトタイプが含まれています 00:10:18.840 --> 00:10:23.240 レポートはデータを収集し請求書や販売レポートのようなドキュメントやレイアウトで提示します 00:10:23.240 --> 00:10:35.480 クエリは特定の期間中にどの顧客が特定の商品を注文したかといったデータに対する絞り込まれた質問を行います 例えばxmlポートは他のシステムと情報をやり取りする必要がある場合などデータを構造化された形式で取り込んだり送信したりするのに役立ちます 00:10:35.480 --> 00:10:42.300 これらの要素を組み合わせれば小規模な顧客報酬エクステンションを構築できます 報酬テーブルには各レベルとその割引率が保存されます 00:10:42.300 --> 00:10:50.180 報酬ページではスタッフがそれらのレベルを管理できます 顧客テーブルエクステンションで各顧客に報酬IDを追加し顧客カードページエクステンションでそれを表示させます 00:10:50.180 --> 00:10:56.620 ページアクションでリワードリストを開きコードユニットで割引ルールを計算します 各オブジェクトがジョブの一部を処理します 00:10:56.620 --> 00:11:06.480 これにより6ヶ月後にビジネスルールが変更された場合でも拡張機能の読み取りテスト変更が容易になります しかしビジネスルールは注文の転記時などまさに適切なタイミングで実行される必要があります 00:11:06.480 --> 00:11:14.160 そこでトリガーとイベントの出番ですイベントトリガーそしてビジネスルール さて顧客リワードフィールドを追加しましたね素晴らしいここからが本題です 00:11:14.160 --> 00:11:18.400 ビジネスセントラルはいつそのフィールドを使用すべきでしょうか 売上注文を転記しようとしている場面を想像してください 00:11:18.400 --> 00:11:25.120 システムが最終的なエントリーを作成する前に追加のチェックを行いたいとします 例えば割引が適用される前に顧客が承認済みリワードレベルを持っている必要があるかもしれません 00:11:25.120 --> 00:11:35.440 あるいは注文を進める前に必要な配送ドキュメントが存在しなければならないかもしれません 適切なタイミングでチェックを行いたいもののたった一つのルールを追加するために販売転記プロセス全体を自分の拡張機能にコピーしたくはありませんよね 00:11:35.440 --> 00:11:41.700 そのプロセスは裏側ですでに多くのことを処理しています コピーしてしまうと将来のすべての変更を維持するために拡張機能を更新し続ける必要が出てきます 00:11:41.700 --> 00:11:49.400 それは理想的ではありませんそこであるは開発者がコードを実行するためのいくつかの方法を提供しています どれを選ぶかは何を実現する必要があるかによりますまずはトリガーです 00:11:49.400 --> 00:11:56.040 トリガーとはあるオブジェクト内のコードを実行できる名前付きの場所です 誰かがテーブルフィールドの値を変更するとトリガーがコードを発火させます 00:11:56.040 --> 00:12:01.580 ページが開いたり閉じたりする際にもトリガーがコードを発火させます レポートクエリ xmlポートテーブル拡張機能 00:12:01.580 --> 00:12:05.940 a o これらすべてに開発者がルールを追加できる場所があります 顧客のリワード id フィールドを例にとってみましょう 00:12:05.940 --> 00:12:12.880 ユーザーがリワードレベルを選択すると検証トリガーを実行できます コードがチェックを行います顧客はブロックされていますかリワードレベルは存在しますか 00:12:12.880 --> 00:12:18.340 他のフィールドを更新する必要がありますか チェックは値が変更されたその瞬間に実行され後でミスが発覚するようなことはありません 00:12:18.340 --> 00:12:23.520 トリガーはルールがそのオブジェクトに密接に関連している場合にうまく機能します しかしビジネスセントラルではイベントも使用されます 00:12:31.580 --> 00:12:38.920 あるいはプロセスが完了したといったことを通知します あなたの拡張機能はその通知をリッスンできますリッスンするコードはイベントサブスクライバーと呼ばれます 00:12:38.920 --> 00:12:44.540 それは特定の名前付きイベントを待ち受けます ビジネスセントラルがそのイベントを発生させるとサブスクライバーが独自のプロシージャを実行します 00:12:44.540 --> 00:12:50.880 標準プロセスはそのまま維持されます 例えばビジネスセントラルが売上注文の転記を開始する際続行する前にイベントを発生させます 00:12:50.880 --> 00:12:59.480 報酬拡張機能がその通知を受け取ります 顧客の報酬IDと割引ルールを確認しますその後処理を続行させるか明確なメッセージを表示して停止させます 00:12:59.480 --> 00:13:06.540 標準の転記処理は依然としてビジネスセントラルが担います 拡張機能はその接続ポイントで独自の会社ルールを追加するだけです 00:13:06.540 --> 00:13:12.900 オンビフォーやオンアフターといったイベント名をよく耳にするでしょう オンビフォーはアクションが完了する前にコードが実行されることを意味します 00:13:12.900 --> 00:13:18.360 これは次のステップを阻止するためのチェックに最適です 条件が満たされない場合に販売オーダーを停止するようなケースです 00:13:18.360 --> 00:13:22.100 アフターはアクションがすでに発生したことを意味します その結果に対して対応できます 00:13:22.100 --> 00:13:27.500 関連レコードの作成メモの更新あるいは別の作業の開始などです 名前がタイミングを示しておりそのタイミングが重要です 00:13:27.500 --> 00:13:32.920 転記後に実行されるルールでは転記を阻止することはできません 逆に早すぎるルールでは必要なデータが揃っていない可能性があります 00:13:32.920 --> 00:13:38.280 そのため開発者はビジネスルールが何をいつ行うべきかに基づいてイベントを選択します コードはアクションから開始することもできます 00:13:38.280 --> 00:13:45.900 ユーザーが報酬ステータスの確認ボタンをクリックするとそのアクションがプロシージャーを呼び出します またあるオブジェクトが変数を介して別のオブジェクトを呼び出すときにコードが実行されることもあります 00:13:45.900 --> 00:13:50.780 難しそうに聞こえますが単純なことです 拡張機能のある部分が別の部分に作業の実行を依頼するのです 00:13:50.780 --> 00:13:59.940 その際に役立つのが変数です変数はコードの実行中に値を保持する名前付きの場所です 数値テキスト日付あるいは現在の顧客のようなビジネスセントラルのレコードでも構いません 00:13:59.940 --> 00:14:07.180 あるでは var を使ってこれらを宣言します 例えば報酬プロシージャはカスタマーという変数を使って現在の顧客レコードを保持します 00:14:07.180 --> 00:14:14.440 ディスカウントパーセントという別の変数は割引率を保持します これらは永続的なレコードではありませんあくまでそのコードを実行するための作業用の値です 00:14:14.440 --> 00:14:19.820 コードの配置場所について説明します ルールが複数の場所で使用される可能性がある場合はコードユニットに配置します 00:14:19.820 --> 00:14:28.480 そうすれば顧客カード販売プロセスレポートのすべてが同じ割引プロシージャを呼び出せます これによりよくある問題を回避できます 00:14:28.480 --> 00:14:34.120 ある画面では10%割引別の画面では5%割引となり どれが正しいルールかわからなくなる問題です 00:14:34.120 --> 00:14:41.460 共有のビジネスルールを一つのコードユニットにまとめることで判断基準を一本化できます つまりトリガーはオブジェクトに近い場所でのルールを処理します 00:14:41.460 --> 00:14:47.340 イベントはビジネスセントラルのプロセスに対して拡張機能が反応できるようにします コードユニットは共有ロジックをまとめて管理します 00:14:47.340 --> 00:14:53.040 これらの要素がつながった後次に問題となるのは開発者はどこであるコードを書き テストし検査するのかということです 00:14:53.040 --> 00:14:59.900 あるの開発は通常ブスコードとも呼ばれるビジュアルスタジオコードで行われます あるファイルを記述するためのワークスペースです 00:14:59.900 --> 00:15:06.220 エクステンションを整理された状態に保ちます 問題の発見を助け完成したアプリをテスト用のビジネスセントラル環境へ送信します 00:15:06.220 --> 00:15:11.800 しかしブスコード単体では汎用的なコードエディターにすぎません マイクロソフトが提供するある言語エクステンションが必要です 00:15:11.800 --> 00:15:16.960 そのエクステンションによりブスコードはビジネスセントラルの仕組みを理解します 入力中にオブジェクト名を提案してくれます 00:15:16.960 --> 00:15:20.840 公開前にエラーを指摘してくれます フィールドやプロシージャの参照を助けます 00:15:20.840 --> 00:15:25.400 そしてプロジェクトをビジネスセントラル環境に接続します これにより多くの推測作業が不要になります 00:15:25.400 --> 00:15:29.400 新しいあるプロジェクトを開始する際はブスコード内である5コマンドを実行します 00:15:29.400 --> 00:15:35.780 プロジェクトの基本フォルダーとエクステンション名発行者バージョン 使用するビジネスセントラル環境を指定する設定ファイルが作成されます 00:15:35.780 --> 00:15:40.520 そのプロジェクトフォルダーをエクステンションの作業台と考えてください すべてのあるファイルはそこに格納されます 00:15:40.520 --> 00:15:44.460 あるファイルにはテーブル別のファイルにはページエクステンション コードユニットには専用のファイルといった具合です 00:15:44.460 --> 00:15:49.220 こうすれば誰かがプロジェクトを開いた時巨大なドキュメントをスクロールすることなく適切なパーツを見つけることができます 00:15:49.220 --> 00:15:55.320 コードがテスト可能な状態になるとブスコードはそれをアプリパッケージにコンパイルします それがエクステンションのインストール可能なバージョンです 00:15:55.320 --> 00:16:04.620 ビジネスセントラルはそのパッケージを読み込みエクステンションを環境に追加します フィールドの不足やスペルミスなどアプリのビルドを妨げる問題があればパッケージがビジネスセントラルに到達する前に 00:16:04.620 --> 00:16:08.180 ブスコードが通知します テストはまずサンドボックス環境で行う必要があります 00:16:08.180 --> 00:16:13.080 サンドボックスとは別のビジネスセントラル環境であり 実際の業務に影響を与えることなく変更を試すことができます 00:16:13.080 --> 00:16:18.720 エクステンションを公開しページを開いて変更を確認し テストレコードを入力してルールが期待通りに動作するかを確認します 00:16:18.720 --> 00:16:24.980 その分離が重要なのです スタッフが業務を行っている最中に新しい検証ルールによって受注電票がブロックされるような事態は避けなければなりません 00:16:24.980 --> 00:16:30.880 サンドボックスなら本番のレコードに影響を与えることなく失敗したり テストデータを削除したりコードを変更して再公開したりできます 00:16:30.880 --> 00:16:40.420 コードは動いていても結果が正しくない場合があります そんな時に役立つのがデバッグです コードにブレークポイントを配置して処理を開始すると実行中にエクステンションが一時停止します 00:16:40.420 --> 00:16:47.140 停止中に現在の顧客や選択された報酬レベル プロシージャが計算した割引率などの値を調査できます 00:16:47.140 --> 00:16:54.660 なぜルールが失敗したのかを推測する代わりにコードが何を受け取ったのかを正確に確認できます 開発チームはgitを使用して作業の履歴を管理することも一般的です 00:16:54.660 --> 00:17:01.840 gitはプロジェクトファイルに対する時間の経過に伴う変更を記録します 誰かがルールを変更して問題が発生した場合チームはバージョンを比較して変更点を確認し 00:17:01.840 --> 00:17:07.020 必要に応じて元に戻すことができます また複数の開発者が同じ拡張機能に取り組む際にも役立ちます 00:17:07.020 --> 00:17:14.320 初心者の場合小さく始めるのが最善の道です まずビジネスセントラルの操作に慣れてから一つのテーブルと一つのページを作成してみましょう 00:17:14.320 --> 00:17:20.520 その後標準ページを拡張して簡単なビジネスルールを追加し イベントやインストールデータがプロジェクトにどう組み込まれるかを学びます 00:17:20.520 --> 00:17:29.500 次にそれらの要素を実際の業務で使える小さなアドオンを通じてつなげてみましょう 簡単な例として顧客特典アドオンを構築します 00:17:29.500 --> 00:17:34.480 実際のある拡張機能とはどのようなものでしょうか 簡単な例に飛び込んでみましょう 00:17:34.480 --> 00:17:41.000 会社で顧客の特典レベルを設定しそれぞれに割引を適用したいと想像してください まずは特典テーブルを作成することから始めます 00:17:41.000 --> 00:17:48.260 各ファイルにID説明割引率を保持するデジタルキャビネットのようなものだと考えてください 例えばゴールドランクなら10%オフといった具合です 00:17:48.260 --> 00:17:56.440 スタッフが技術的なツールに触れることなくそれらのレベルを管理できるようにする必要があります そこで全レベルを表示する特典リストページと編集や作成を行う特典カードページの2つを追加します 00:17:56.440 --> 00:18:01.900 開発環境を開かなくてもスタッフは新しいレベルの追加やパーセンテージの調整 内容の確認を行うことができます 00:18:01.900 --> 00:18:12.060 次に顧客テーブルを拡張して特典IDという新しいフィールドを追加します そのフィールドは各顧客を一つの特典レコードに紐付けスタッフが顧客情報を管理する顧客カードページにそのフィールドを配置します 00:18:12.060 --> 00:18:19.520 さらに特典アクションを追加し同じカードから直接特典リストを開けるようにします 割引ルール自体はコードユニットの中に配置されます 00:18:19.520 --> 00:18:26.560 他のプロセスで顧客の割引が必要な場合ページごとに何度も計算するのではなくそのコードユニットを呼び出します これが効率的です 00:18:26.560 --> 00:18:34.440 インストールコードユニットは拡張機能が初めてインストールされた時に初期特典レベルを追加します そしてイベントサブスクライバーが販売プロセス中に選択された特典レベルをチェックし 00:18:34.440 --> 00:18:39.680 適切なタイミングで会社のルールを適用します 小さな拡張機能ですがその中身に注目してください 00:18:39.680 --> 00:18:46.280 データテーブルユーザー画面ナビゲーションアクション設定ロジックそしてビジネスルールがすべて連携して機能しています それこそがあるの真の力です 00:18:46.280 --> 00:18:51.040 さて結論としてある開発の出発点についてです まとめると以下のようになります 00:18:51.040 --> 00:18:56.680 ある開発を使えばコアアプリケーションに触れることなく会社が必要とする特定の機能を ビジネスセントラルに追加できます 00:18:56.680 --> 00:19:02.260 すべてを一度に構築する必要はありません まずは一つのフィールド一つのページ拡張そして一つの明確なルールから始めましょう 00:19:02.260 --> 00:19:08.160 それがあなたの最初の構成要素となります 今回の知識のヒントが役立ちましたらお気に入りのポッドキャストプラットフォームで登録し 00:19:08.160 --> 00:19:13.760 ビジネスセントラルの開発を始めたばかりの方と共有してください 次回もまたパズルのピースを一つ埋めていきましょう 00:19:13.760 --> 00:19:19.180 マーコピーターズがお届けした m 365 fm のマイクロソフト知識のヒントでした