• 6 分

開発者は、Microsoft Power Platform のアプリについて、目的のビジネス アプリケーション機能を達成するためのコーディングは、ノーコードやローコード アプローチの例外と見なす必要があるという視点からアプローチする必要があります。 ただし、特定のシナリオに対して最適なアプローチを決定する際には、保守性、移行性、安定性、パフォーマンスなどの品質区分も考慮する必要があります。

Microsoft Power Platform ですぐにできることを理解しておけば、Power Platform が既に行っていることや、単に構成すればよいだけのものを構築する必要がなくなります。 これは、使用可能な Dynamics 365 アプリで実装されている機能にも当てはまります。 たとえば、複数通貨の変動価格表を使用した請求計算は複雑ですが、これらの計算は Dynamics 365 Sales で適切に実装されており、その有効性は実証済みです。 この機能が必要な場合は、独自の計算エンジンを実装する代わりに、Dynamics 365 Sales に組み込まれている機能の使用を検討するべきです。

また、多くの場合、Microsoft Power Platform では、プラットフォームに有益な方法で実装を行っていることも認識する必要があります。 こうした方法は、カスタム アプリケーション コードでの方法に慣れていると、異なる場合があります。 Microsoft Power Platform ソリューションの構築に初めて取り組む開発者が、以前にカスタム アプリの構築に使用した方法でプラットフォームをカスタマイズしようとするのは珍しいことではありませんが、 可能であれば避けるべきです。また、自分が慣れている方法に合わせてプラットフォームを変えるのではなく、プラットフォームの優れた点を活用する必要があります。 たとえば過去に、カスタム コードを使用して列レベルのセキュリティを実装したことがあるとします。 しかし、列レベルのセキュリティは Dataverse に既に組み込まれており、構成するだけで使用できるため、コーディングを行う必要はありません。

ビジネス ルールとクライアント スクリプトの比較

ビジネス ルールの利点は、開発者以外にもわかりやすく、実装も容易であり、さらに実稼働環境でのデプロイ向けに Dataverse ソリューションの一部として含めることができることです。 開発者のスキルが手軽に利用できず、アプリケーション ライフサイクル管理が行われていない組織では、いくつかの回避策が必要な場合でも、ロジックを実装するのにビジネス ルールが望ましい方法となります。例として、ルールで確認する値を保持する中間の計算フィールドなどがあります。

ただし、ビジネス ルールでは業務上の要件を実装できなかったり、ルールが複雑なことから、開発者がクライアント スクリプトでロジックを記述する方法を好んだりする場合も時にはあります。 このようなシナリオの 1 つとして、入れ子になった複雑な「if/then/else」ロジックがあり、switch ステートメントまたは if ブロックの単純なシーケンスで実現する方が適切な場合が考えられます。 もう 1 つは、ビジネス ルールで容易にアクセスできない動的な値を処理する場合です。 たとえば、フォーム通知やフィルター処理オプションの値は、ビジネス ルールでは使用できません。

ワークフロー/Power Automate フローとプラグインの比較

Dataverse には、システム内のイベントに応答するロジック、特にデータ行の作成、更新、削除などのデータ変更に応答するロジックを実装するためのさまざまな方法が用意されています。 業務上の要件は、ワークフローを使用するノーコード ソリューションと Power Automate、およびサーバー側 (プラグイン) またはクライアント側 (スクリプト) コードを使用して Dataverse を拡張することで満たすことができます。

ビジネス ルールとクライアント スクリプトの比較で使用した方法と同様の方法で、業務上の要件とそれらの要件を実装するために必要な組織能力を見定め、オプションを評価するとよいでしょう。 機能にはいくつかの基本的な違いがあります。 次のテーブルは、一方のアプローチの代わりに他方を使用した方がよいかどうかを判断するのに役立ちます。

機能	Power Automate フロー	ワークフロー	プラグイン
同期または非同期	非同期	いずれか (非同期ワークフローの代わりに Power Automate フローが推奨されます)	いずれか
外部データへのアクセス	可 (コネクタを使用)	不可	可 (API を使用、いくつかのセキュリティ制限あり)
メンテナンス	作成者	ビジネス ユーザー	開発者
実行できる主体	現在のユーザーまたはフローの所有者	現在のユーザーまたはワークフローの所有者	ライセンスを持つユーザー、システム、または現在のユーザー
オンデマンドで実行できる	可	可	不可
子プロセスをネストできる	可	可	可
実行段階	後	前/後	前/後
トリガー	作成、列の変更、削除、オンデマンド、スケジュール	作成、列の変更、削除、オンデマンド	作成、列の変更、削除、カスタムを含むその他のメッセージ

Microsoft Power Platform は継続的に進化するため、開発者は、新しい機能と今後リリース予定の機能を把握しておく必要があります。 たとえば、ソリューションでカスタム設定または構成値が必要だった場合、以前はカスタム テーブルを使用してこれらの値を格納し、カスタム コードまたはプラットフォーム ツールを使用してデータをデプロイする必要がありました。 新しく追加された環境変数により、このタスクは簡素化され、変数を宣言し、ソリューションの一部として含め、値を設定するだけで済むようになりました。コーディングは一切必要ありません。

Power Apps Component Framework (PCF)

長年の間、モデル駆動型アプリにおけるクライアント側の拡張メカニズムとして、HTML Web リソースが主流でした。 このアプローチの弱点の 1 つとして、拡張できないモノリシックな要素の再利用が低かったことがあります。 今は、HTML Web リソースが PCF コントロールに置き換えられています。

PCF を使用すると、開発者は、標準のコントロールの代わりに、作成者が再利用できるコンポーネントを作成できます。 これは、プラットフォーム機能の進歩によって、ビジネスが堅固なインフラストラクチャを構築し、アプリ作成者に力を与えることに開発努力を集中させられるようになるという良い例です。

外部システム

外部システムとの通信は、ソリューション実装の一般的な機能です。 SMS メッセージの送信や為替レートの更新のような単純なタスクから、複雑なデータ同期シナリオまで、以前は開発者に限定された領域でした。 実装では、プラグイン、サービス エンドポイントを介したイベント発行、Webhook が使用されていたのが、

数百のコネクタを備えた Power Automate の導入により、アプリ開発者がコードを使用せずに外部システムとのやりとりを実装できるようになりました。

しかし、これによって、開発者の役割が不要になるわけではありません。 コーディングが必要となる複雑なシナリオや高性能なシナリオは数多くあります。 さらに、開発者は、構築ブロックの接合を作成担当者に任せながら、サービスやカスタム コネクタの作成に集中して取り組むことができるようになりました。

ポータルとカスタム サイトの比較

Power Pages には、すぐに使えるさまざまな機能が備わっており、この機能を使用すると、開発者は信頼性の高い Web サイトを作成し、必要に応じて拡張することができます。 多くの場合、開発者は、高度なページ レイアウト (Liquid テンプレート言語を使用) や JavaScript を使用したフロントエンド サイト機能の拡張など、より複雑なポータル タスクを支援します。

専門性の高いシナリオでは、ASP.NET や同様の技術を使用して、完全なカスタム ポータルを作成することができます。 このアプローチは珍しいものではありませんが、実装するには高度なスキルを持つ開発者が必要です。 この場合も、標準であるが一般化された機能をノーコードで実装するか、開発者のリソースを管理しながら使用して特殊な機能を提供するか、の 2 つの選択肢の間で妥協点を見つけることになります。

コードを使用するタイミングは、単純に二者択一で決められるものではありません。 どのようなスキルやリソースを使用できるか、アプリケーション ライフサイクル管理における組織の成熟度、要件の複雑さなど、さまざまな要因を考慮する必要があります。多くの場合、業務上の制約についてほんの少し妥協することで、ソリューションを簡素化し、複雑な開発プロジェクトを簡単な構成作業に単純化できる可能性があるため、要件をケース バイ ケースで評価する必要があります。

あらゆる開発者にとって、プラットフォームで何ができるかについて最新かつ確かな知識と理解を持っておくことは、コードを使用するべき場合と、作成者やビジネス ユーザーがカスタマイズし、構成できるようシステムを適合させるべき場合を合理的かつ常識的に判断するために不可欠です。