Aprouveは、既にお使いのスタックに適合します。

なぜ重要なのか

自動承認ワークフローとバージョン管理を備えたほとんどのマーケティングプラットフォームには、統合の制限があります。統合がうまくいかないワークフロープラットフォームのコストは、最初はほとんど見えません。後になって、3つの予測可能な方法で現れます。

1つ目は、データの重複入力です。Aprooveがプロジェクト管理システムからプロジェクトデータを取得できない場合、プロジェクトマネージャーはプロジェクトを2回作成します。1回は上流システムで、もう1回はAprooveで作成します。2回目のコピーのエラー率は、統合が不十分なことによるコストです。

2つ目は、ワークフローの継ぎ目が壊れることです。Aprooveでの決定が、ERP、MAM、またはスケジューリングシステムの下流アクションをトリガーできない場合、それらの引き継ぎはメールタスクになります。自動化されるべき人間の手順は手動のままで、監査証跡は継ぎ目が壊れます。

3つ目は、IDのスプロールです。IDプロバイダーを通じてユーザープロビジョニングが自動化されていない場合、ITチームはメインのIDディレクトリとは別にAprooveでユーザーリストを管理します。組織に出入りする人がいても、Aprooveのアクセス権はそれに応じて変更されません。

コンプライアンス体制が悪化します。

エンタープライズアプリケーション統合ツールは、これら3つの課題すべてに対応します。プロジェクトデータは上流システムから自動的に流入します。承認決定により、下流のアクションがリアルタイムでトリガーされます。ユーザーアカウントはIDプロバイダーによって作成および削除されます。プラットフォームは接続状態を維持します。

統合ツールキット

Aproove RPC API V2.0。 プラットフォームの完全なプログラム操作インターフェースです。プロジェクトの作成、ファイルのアップロード、ワークフローのトリガー、決定の取得、監査データのエクスポート、構成管理、およびユーザー管理はすべて、REST/RPC コールを介してアクセスできます。API はドキュメント化されており、バージョン管理のサポートがあり安定しています。

Concoord ミドルウェア。 Node-RED 上に構築された Concoord は、ノードを接続してフローを構築するビジュアル統合ビルダーを提供します。事前構築済みのノードには、Aproove RPC ノード (任意の Aproove API コール用) と Adob​​e Workfront コネクタ (任意の Workfront API コール用) が含まれます。他のシステム用にカスタムノードを追加できます。 Concoord は Aproove と並行してデプロイすることも、独立してデプロイすることもでき、複数のシステムにまたがる統合ロジックを実行でき、分岐、条件付きロジック、変換、エラー処理などが含まれます。

Aproove の Webhook。 Aproove でイベント (プロジェクトの作成、ワークフロー ステップの完了、決定、ファイルのアップロード、AI エージェントの呼び出しなど) が発生すると、Aproove はサブスクライブされたエンドポイントに Webhook 呼び出しを送信できます。Concoord、独自の統合レイヤー、または任意の HTTP リスニング サービスがこれらのイベントを受信し、リアルタイムで処理できます。

ホット フォルダー。 API を持たないレガシー システムとのファイル ベースの統合のために、Aproove はホット フォルダーをサポートしています。ホット フォルダーは、ファイル名の規則または付随するサイドカー ファイルからメタデータが取得され、ファイルが現れると自動的にファイルを取り込むファイルシステム ロケーションです。

外部システムを呼び出すワークフロー アクション。 Aproove ワークフロー内では、個々のステップにワークフローの途中で外部システムを呼び出すアクションを含めることができます。 「Concoord 呼び出し」アクションは、同期または非同期で Concoord フローを呼び出します。「Concoord 呼び出しとコールバック待ち」アクションは、Concoord フローを呼び出し、外部システムが応答するまでワークフローを一時停止します。つまり、外部システムは、オブザーバーとしてではなく、完全な参加者として Aproove ワークフローに参加できます。

事前構築済み統合

Adobe Workfront。 最もドキュメント化された事前構築済み統合です。Workfront で開始されたプロジェクト作成フローは、Workfront カスタムフォームから Concoord を介して Aproove に流れ、プロジェクトのメタデータ、ファイル、マイルストーンが同期されます。ポーリングベースと Webhook ベースの両方のパターンがサポートされています。Aproove の決定は、タスク ステータスを更新するために Workfront にフローバックできます。Workfront コネクタには、組み込みのページネーションが含まれており、Workfront の REST アーキテクチャに従います。

ID プロバイダー。 自動プロビジョニングを備えた SAML 2.0 SSO は、ファーストクラスの機能です。 Active Directory (Kroger パターン)、Azure AD (一般的には Kingspan パターン)、および Okta との統合が文書化されています。LDAP は、従来の ID システムでサポートされています。グループのプロビジョニングとプロビジョニング解除により、ID グループに参加または離脱したユーザーは、連絡先グループのメンバーシップを含め、Aproove へのアクセス権を自動的に取得または喪失します。

Concoord によるカスタム統合 事前構築済みのコネクタ以外にも、Concoord は、REST API または Webhook エンドポイントを持つほぼすべてのシステムと統合できます。ERP システム、スケジューリング システム、資産管理プラットフォーム、および自社開発アプリケーション向けに、顧客構築の統合が存在します。例えば、Kroger の導入では、「Kroger のスケジュール システムと Aproove の深い動的な統合」により、週 600 を超えるスケジュール済みワークフロー トリガーが実行されます (Kroger Promotional Execution Centre of Excellence Transformation ホワイト ペーパー、Aproove、2021 年 10 月)。

ID 統合

ID は、ユーザー ライフサイクル、権限管理、監査帰属、コンプライアンス スタンスなど、多くの要素に影響するため、それ自体が統合ストーリーとなります。

Aproove は SAML 2.0 SSO をサポートしており、顧客の ID プロバイダーが IDP として、Aproove がサービス プロバイダーとして機能します。認証は顧客の既存のインフラストラクチャを介して行われます。Aproove は SSO ユーザーのパスワードを保持しません。

自動プロビジョニングにより、これが拡張されます。ユーザーが顧客のディレクトリの ID グループに参加すると、適切な役割と連絡先グ​​ループのメンバーシップで Aproove にプロビジョニングされます。ユーザーがグループを離れると、アクセス権がデプロビジョニングされます。 ID プロバイダーが真実のソースです。Aproove はそれに従います。

SSO ユーザーの場合、Aproove は「ユーザー ID の強制」機能もサポートしており、特定の決定ポイントでユーザーの SSO ID を再検証します。これにより、FDA 21 CFR Part 11 の電子署名要件や、元の SSO 認証では不十分な同様の資格確認フローがサポートされます。

一般的な統合パターン

フォーム駆動型プロジェクト作成。 ユーザーが上流システム (Workfront、SharePoint、カスタム入力ポータル) でカスタムフォームに入力します。フォームの送信により Concoord フローがトリガーされ、キャプチャされたメタデータを使用して Aproove にプロジェクトが作成され、ファイルが添付され、ワー​​クフローが開始されます。

イベント駆動型ワークフローオーケストレーション。 Aproove は、主要なワークフローイベントで Webhook を発火します。外部システムはこれらのウェブフックを購読し、ERPレコードの更新、製造オーダーのリリース、チャットチャネルへの投稿、下流レビューのトリガーなどのアクションを実行します。

ワークフローの中間での外部呼び出し。 Aprooveのワークフローステップは、タスクを実行するために外部システムを呼び出します。ステップは外部からの応答を待ってから続行します。このパターンにより、Aprooveは外部ステップを含む作業をオーケストレーションでき、監査証跡には外部の参加が記録されます。

ホットフォルダの自動化。 レガシーシステムは、監視対象ディレクトリにファイルをドロップします。Aprooveはファイル名またはサイドカーメタデータに基づいてプロジェクト割り当てを行い、それらを自動的に取り込みます。中間に人間はいません。

ID駆動型ユーザーライフサイクル。 ユーザーは、顧客のディレクトリ内のIDグループに追加または削除されます。Aprooveのプロビジョニングは自動的に実行されます。役割の割り当て、連絡先グループのメンバーシップ、およびアクセス権限は、ディレクトリに合わせて更新されます。

メリット

• データの重複入力は不要です。 プロジェクトデータは上流システムから自動的に取り込まれます。
• ワークフローは途切れません。 承認決定により下流アクションがトリガーされ、外部システムがワークフローステップとして参加できます。
• IDはクリーンな状態を維持します。 自動プロビジョニングとデプロビジョニングを備えたSAML 2.0 SSOにより、ユーザーアクセスは信頼できる情報源と一致します。
• 重要な箇所は事前に構築され、必要な箇所はカスタマイズされます。 Adob​​e Workfrontには、ドキュメント化された事前構築済みの統合機能があります。それ以外のものはすべて Concoord と API を介して統合されます。
• 統合ロジックはコードに埋もれることなく視覚的に表現されます。 Concoord の Node-RED 基盤により、統合フローは開発者だけでなく統合アーキテクトによって視覚的に構築および保守されます。
• 監査証跡は統合境界をまたぎます。 Webhook イベントと Concoord 呼び出しイベントは、プラットフォーム内イベントとともにプロジェクトレコードに記録されます。‍
• オープンアーキテクチャ、ベンダーロックインなし。 REST/RPC API、標準プロトコル (SAML、Webhook)、オープンミドルウェア (Node-RED)。独自のものが統合パスを妨げることはありません。

対象者

• 既存のエンタープライズシステムとの適合性を評価するワークフロープラットフォームを評価するITおよび統合アーキテクト。
• 上流のプロジェクト管理、スケジュール管理、またはERPシステムに依存するレビュープログラムを実行するマーケティングオペレーションリーダー。
• 企業IDプロバイダーを介した自動ユーザープロビジョニングおよびデプロビジョニングを必要とするIDおよびアクセス管理チーム。
• 特にAdobe Workfrontを使用している顧客で、カスタム構築ではなく、事前に構築された統合を希望する顧客。
• 最新のAPIファースト統合ではなく、Webhook、ホットフォルダー、またはスケジュールされたAPI呼び出しによる統合を必要とするレガシーシステムを使用している顧客。

内部構造

Aproove の統合アーキテクチャは、次の 4 つの柱を中心に構築されています。Aproove RPC API (REST over HTTP、バージョン管理、完全なドキュメント付き)、Aproove Webhook フレームワーク (サブスクライバーエンドポイントに HTTP POST コールバックを発行する設定可能なイベントサブスクリプション)、Concoord ミドルウェア (Aproove RPC および Adob​​e Workfront コネクタが事前に構築された Node-RED ベースの統合プラットフォーム)、および SAML 2.0 SSO フレームワーク (Aproove がサービス プロバイダーとして機能し、顧客の IDP が認証アサーションを発行し、SAML 属性を介してグループ プロビジョニングがサポートされます)。ワークフロー アクションには、Concoord 呼び出しと Concoord 呼び出しとコールバック待ちがあり、ワークフロー ステップで外部システムを同期または非同期で呼び出すことができます。ホット フォルダーは、従来のファイル駆動型統合のためのファイルシステム ベースの自動入力を提供します。ワークフロー イベント (プロジェクトの作成、ステップの完了、決定、ファイル イベント、AI エージェント イベント) は、Webhook サブスクリプションとして利用できます。 Aproove Concoord のデプロイメントは、Aproove と並行して実行することも、独立して実行することもできます。複雑な統合フローの例が文書化されています (Workfront プロジェクト作成フロー CD/560859786、Workfront 統合サンプル CD/560859689、Concoord 入力エンドポイントと Aproove RPC ノード CD/566493214)。統合レイヤーは、プラットフォーム本体と同じ監査証跡標準を維持します。統合境界を越えるイベントは、タイムスタンプ、属性、および必要に応じてペイロードの詳細とともにプロジェクトレコードに記録されます。