統合のパターン: デジタルスレッドのための PLM

00:00 統合パターンへようこそ。 デジタルスレッド用 PLM 私の名前はヘマチャンドラです。私は PTC Windchill チームのプロダクトマネージャーです。 この会話では、主に Windchill のサービスを担当しています。 今日はホリー・ランドシーも一緒にいます。また 、PTC のプロダクトマネージャーも務めています。 彼女はSaaSプラットフォームチームの一員です。

00:30 そこで、今日は、 PLMプラットフォームにデジタルスレッドを実装するためにどのような統合パターンを使用するか、 どのような統合パターンとテクノロジーを使用するかについて 、作成したコンテンツの一部を紹介します。 それでは早速見ていきましょう。 デジタルスレッドに関する最初のコンセプトから始めようと思いますよね？

01:07 PTCのロゴ、 陰と陽、右。 つまり、 その本質的な目的は、 企業内だけでなく、企業全体にわたって、 適切な情報を適切な人に適切なタイミングで、 適切な状況で提供できるようにすることです。 では、 その目標をどのように達成し、実際に何を意味するのかということです。 正しい。つまり、基本的には、これらすべてが、

01:42 デバイスに接続されている場合もあります。 ビジネスシステムには非常に多くの種類があります。 そして、 どのスレッドを引っ張ってもそのスレッドを引っ張って、 たとえば製品などの物理的な部分について、必要な情報にアクセスできますよね？ たとえば、すべての企業が完全な成熟度レベルに達するわけではありませんよね。

02:15 始めたばかりの人もいるかもしれません。 彼らは、 エンジニアリングなどの特定の機能内のシステムだけを接続したいと考えています。 たとえば、 エンジニアリングと製造などの機能間でシステムを接続している企業もあります。 そして、 拡張されたバリューチェーン全体で実際にシステムを接続している企業は非常にまれかもしれません。 しかし、それこそが最初のアイデアです。

02:46 そして、 これらはPTCがさまざまなお客様と協力して考え出した数字です。 繰り返しになりますが、 これらすべての数値にこだわりたくはありませんが、たとえば、 これらすべてのシステムが相互に接続されていれば、 どれだけの効率を上げることができるかがわかります。 正しい? ちょっとした例を挙げると、 エンジニアリングの重大な変更が実際に契約メーカーに影響を与え、 その情報が時間内に届いたら、 廃棄コストを節約できるかもしれません。

03:16 つまり、 そういうことが積み重なって、 さまざまな効率を上げることができるのです。 PLM プラットフォーム上でデジタルスレッドを構築する一番の動機はそこにあるのです。つまり、 言うは易く行うは難しですよね？どうやってやるの？ これは大きな問題で、 これらのシステムを構築して統合するのに役立つ、 大まかに見ることができるパターンがいくつかありますよね？ 左の図では、

03:48 基本的にこのポイント・ツー・ポイント・パターンが見えますが、 これはほとんどの人がよく知っていることだと思います。 ねえ、 マスターデータシステムをPLMシステムに接続する必要があります。オッケー。 つまり、1 つの 1 つの接続です。 ご存知のように、 ERPシステムと通信するにはPLMシステムが必要です。それは別のつながりです。 つまり、 このポイントツーポイント接続を行うと、 すべてがかなり速く膨らむということですよね？ したがって、

04:18 ある機能部門に所属していても、これらのシステムを 1 つずつ接続しようとしても問題ありません。 大丈夫です。 管理できるかもしれないけど、 特定の部署を超えると手に負えなくなりますよね？ そこで役立つ 2 つ目のパターンが 、Issi バスパターンです。 つまり、 これらのアプリケーションはすべて共通のスキーマに接続されているということですね。まるで

04:50 回路基板上のバスのようなものです。 これが一般的なスキーマです。 各アプリケーションのそれぞれが共通のスキーマに貢献し、 その共通スキーマがデータと他のすべてのシステムを同期させることができます。 これはかなりよく採用されているパターンです。 ここにいる皆さんの多くは、 TibcoやActivemqなどの会社でこのようなものを持っていると思います。 これらのミドルウェアタイプのシステムは、 通常、彼らが実装するパターンです。 実際、PTC は簡単なソリューションです。 また、 このパターンには共通のスキーマが付いていて、他のすべてのエンタープライズシステムをそのように接続してみることができますか

05:33 このパターンを拡張企業全体に拡大しようとしてもうまくいかないのはどうでしょう？なぜなら、 これは主にGmmsのようなプロプライエタリなプロトコルに基づいているからです。 これは単なるAPIですが、gemsですよね。 実際にはベンダーが提供するプロトコルがあります。たとえば、私が東電なら、 2つの異なるシステムを接続するランデブーというプロトコルがあるかもしれません。 これは標準プロトコルではなく、 そのプロトコルの上でJMS APIを有効にしているだけです。

06:05 そして通常、 このような独自仕様のプロトコルは、 ご存知のようにファイアウォールを越えるのが難しく、 企業の境界を越えることも困難です。正しい? では、次のパターンは何でしょうか？ たとえば、 社外の企業と接続したい場合など、どうすればよいでしょうか？ つまり、このパターンでは、 すべてのビジネスシステムが実際にREST APIを開いているということですね。 そして、REST APIについて聞いたことがあると思います。 これについては、Windchill のコンテキストで少し説明します。

06:37 しかし、いったんこれらのREST APIが利用可能になれば、 APIやオーケストレーションツールが実際にそれらのRESTエンドポイントを呼び出し あるシステムからビジネスデータとデータを引き出し、別のシステムにプッシュすることができます。 そのため、 システム間で情報をプッシュしたりプルしたりするフローを調整できます。 実際、このパターンはすべて HTTP ベースなので、 拡張企業全体で統合を構築するうえで非常に適したパターンです。 そして、 あなたは自分が抱えているような問題にはあまり対処していません。

07:10 だから先に進みましょう。つまり、基本的に、 これら3つの大まかなパターンの中には、 すでにご存じのものもあります。 それでは、Windchill サービスについて見ていきましょう。 それが、 今日はそのことについてもう少し深く掘り下げたいと思います。 つまり、Windchill サービスは Windchill 上に構築したモジュールです。 11.0 M30から利用可能になったので、 しばらく前から存在していますよね？

07:44 基本的にはオアシスの標準であるODATA規格に基づいており、ISOの承認を受けています。基本的に、 これはこうした RESTful サービスや REST API を構築して利用するための標準です。 そこで、 私たちはあるパターンに従わなければならないと決めました。 ここでは標準に従う必要があります。そうすると Windchill システムがオープンになるからです。 これらの OData エンドポイントを使用して Windchill の情報にアクセスできる市販の市販のツールならどれでも使用できますよね？つまり、 このモジュールをロールアウトするときに、基本的に Windchill

08:16 のすべてのアクティブなメンテナンスリリースでそれをサポートするようにしています。このモジュールは cpses 経由でインストールされ、 Windchill を初めてインストールするときにインストールされます。 これが次のバージョン、2.6です。 先ほどお話ししたリリースである6月にリリースされる13.0にバンドルされています。 そして、 そこにリストアップしたCPSでも利用できるようになります。 だから、なぜREST APIを構築するのかなど、 これについてはすでに少し触れたと思います。

08:48 つまり、基本的に3つの主な理由ですね。 モダンな UX の基盤になることはわかりましたよね？ そして、 現在見ているどのシステムでも、モダンな UI を構築しているシステムでは、 React や Angular などのフレームワークを使用していますよね？ そして、これらのフレームワークはすべて、 関心事の分離に基づいて構築されていますよね？ すべてのJavaScriptと同様に、 ブラウザで実行できます。別々です。 しかし、そのシステムでは、RESTful APIを介して一部のバックエンドサービスを呼び出します。 つまり、

09:19 私たちが構築しているものは本当に優れた基盤であり、Windchill からデータを取得するためのあらゆる種類の新しい UI フレームワークで使用できます。 これはクラウド API 統合の基盤です。 前にも言いましたが、 従来のパターンでは企業の境界を越えるのは難しいですが、このRESTful APIパターンでは、 Httpで簡単にそれができ、 それが一番の理由です。 そしてもちろん、オープンな PLM 標準ベースの基盤にもなります。

09:51 指差すこともできます Excel スプレッドシートやその他の Power BI タイプのツールを使用して、残りのエンドポイントにアクセスします。 Windchill からデータを取得し、ダッシュボードを構築し 、やりたいことを何でもできます。 それでは、アーキテクチャについて簡単に説明します。 つまり、 基本的にはフレームワークの上に構築されているということですね。 つまり、 基本的にこのフレームワークでできることは、これらの Windchill

10:22 ビジネスオブジェクトを RESTful な種類の API エンドポイントとして公開することですよね？ URLリソースのようなものですね。 そして、これらのリソースを Http 経由で操作できます。 一般的な動詞と同じく従来の動詞を使うだけです。 パーツを作成する場合は、POST リクエストを使用するとよいでしょう。 部品を削除する場合は、 HTTP の削除リクエストを使用すると 、 基本的に Http だけで Windchill ビジネスオブジェクトを操作できます。右。これが可能になるのです。

10:52 このフレームワークでは、 Windchill ビジネスオブジェクトを公開すると その製品管理ドメインが公開されます。ドキュメント管理ドメインなど。 これらはすべて安らかなサービスです。 それらをドメインと呼びます。 ただし、Windchill の各機能領域には、 主に扱っているオブジェクトを公開する独自のドメインがあります。 特にオンプレミスインストールの場合は 、カスタムドメインを構築することもできます。じゃあ何があるんだ？ これまでのところ、 私たちはこのことに数年間取り組んできました。右。

11:23 つまり、 これらの種類のドメインはそのまますぐに利用できるということです。そして 私が強調表示したものは、おそらく赤いアウトラインで表示されます。 これらが PTC の主な重点分野です。 これこそまさに、Windchill のカスタマイズなどで行うことの基本です。 製品管理、ドキュメント管理、 その他すべての機能分野を見てみると、 現在利用できるサービスはかなり充実しています。

11:54 作成したり、 削除したり、更新したりできます。 背景が黄色いCrudの操作はすべてサポートされていますが、 他の操作ほど機能が進んでいない可能性があります。 右。 しかし、 それでも基本的な読み取り機能や、チェックアウトやチェックイン、 そういう内容の修正などの基本的な機能があります。 ただし、まだやるべきことがあるかもしれません 。たとえば、 プリンシパル管理ドメインで、 現時点ではほとんど読み取り専用です。

12:25 正しい?ですから、私が喜んで対応したり、 要件やタイプに関するものがあったり、Windchill 喜んでお話を聞かせてください。 つまり、たくさんのドメインです。 それでは、PTC の優先度の高い分野について少し触れておきましょう。正しい。 そのため、 変更管理の分野では、ドメインはかなり成熟しています。 現在もほとんどの機能に取り組んでいるところです。

12:57 ですから、 変更リクエストの閲覧や更新などは許可していますが、 プロモーションリクエスト用に作成することはできないと思います。 ドキュメント管理ドメイン。 繰り返しになりますが、 ここにはまだ取り組まなければならない分野がたくさんあります。 基本レベルのドメインは用意されていますが、完全に機能する API を提供するには、 これらすべてに取り組む必要があります。 しかし、先ほど申し上げたように、

13:27 これらはPTCにとって最優先事項であり、 現在取り組んでいることですよね？ ほら、 部品表を作成したり、読んだり、 ドキュメントを関連付けたりなど、ほとんどのことができます。 これらは、 関連性という観点からまだ明らかにしなければならない分野の一部です。 部品を持っている場合など、 その部品からナビゲートして関連ドキュメントを見ることができますか？ 正しい?ですから、 これらは私たちが取り組んでいる優先度の高い分野のいくつかですね。これらのほとんどは、 お気づきの方もいらっしゃると思いますが、 ある部分から始まって外に出ていく関係ばかりです。

14:00 同様に、 文書管理はかなり成熟したプリンシパル管理です。 前にも言ったように、成熟していません。 今ではかなり有能なドメインですよね？ プロセスプランなどを使用して、あらゆる種類の Crud 操作を実行できます。 ですから、ぜひ見てみることをお勧めします。 しかし、最近になってこれが多くの進歩を遂げました。 これがWRC 2.6で予定されていることです。 そこで、Java 17 のサポートに取り組んでいます。

14:34 早速説明させてください カスタムドメインを構築する場合、 あるドメインが別のドメインをインポートし、そのドメインを元に戻して最初のドメインをインポートすることは可能ですよね？そのため、 これらの循環依存は問題を引き起こす可能性があります。 そこで、 これを検出して通知するツールを作成しました。 ねえ、ほら、 カスタマイズして構築しているドメインが何であれ、循環依存関係があります。 今後は統合された単一レベルと複数レベルのボムレポートを確認するための新しいアクション、 ドキュメント管理があります。

15:07 繰り返しになりますが、 ドメインでも同じアクションを提供しています。 そしてもちろん、 これが私の最後のスライドだったと思います。 みなさん、こんにちは。今日は、フローと呼ばれる Windchill 向けのもう 1 つの統合テクノロジーについてお話しします。 Flow は、アトラスと呼ばれる PTC SaaS プラットフォームの一部です。

15:39 今週、 あなたはそれについてたくさん聞いたと思います。 Atlasは、 当社のplusおよびSaaS製品に対してSaaSサービスを提供しており、 当社が提供するサービスの1つは、 フローによるデータ統合およびオーケストレーションサービスです。 では、フローとは何でしょうか？ Flowは、お客様がワークフローを構築したり、異なるデータシステムを接続したり、 ビジネスプロセスを合理化したりするために使用できるローコード、 ノーコードのワークフローエンジンです。 また、flow には、

16:14 そのため、flowには、 そのうちのいくつかはPTCシステムなので、Arenaです。 ウィンドチル。ウィンドチル。SaaS。ThingWorx。 また、SAP、 Salesforce Dynamics 365などの他のエンタープライズシステムへのコネクタや、 つまり、Slack、Gmail、Azure、 Blob Storage、Dropboxなどは、

16:47 また、 必要なものに対応するコネクタがない場合でも、 つまり、 これらはodataやHTMLなど用の標準ベースの汎用コネクタです。 また、これらを使用して、 自社製のシステムや、 コネクタがないエンタープライズシステムに接続できます。 コネクタは、認証 、検索、トリガー、 つまり、 これらのアクションを実際に使用してワークフローを構築することになります。 各ワークフローはトリガーから始まります。

17:17 この例では、Windchill の状態の変化がワークフローを開始していることがわかります。 その状態変化が発生すると、 そのため、この場合は、 リリースされたパーツの情報を Windchill から取得します。 ここにスイッチユーティリティがあるのがわかります。 だから、 他のロジックを組み込んでいるだけです。 このリリースパーツに特定の属性がある場合は、 この最初のパスを採用します。 その場合は、 図面ファイルをboxにアップロードし、

17:47 サプライヤーに見積もりを依頼するメールを送信します。 別の属性に基づく別の状況では、そのパーツを Trello のリリースボードに追加するかもしれません。 では、 これはデジタルスレッドにとって何を意味するのでしょうか？ Hamontが述べたように、 統合について私たちが通常見てきたのは すでに説明したように、 統合しようとしているシステムの数が増えるにつれて 、これはかなり管理が難しくなります。

18:18 そのため、 Floがオーケストレーションレイヤーとして機能するようになったため、 アプリケーションチームはFloへの接続だけを考えて、 残りのAPIを使用してさまざまなシステムへのすべての接続をFloに処理させることができます。 そこで、 Flowのミッションであるシフトについて少しお話しします。 先ほどお話ししたように、私たちはアトラスの SaaS

18:50 プラットフォームと SaaS ビジネスの一部です。Unit Flow は以前は ThingWorx プラットフォームの一部であり、 実際には自分で構築できる統合ツールキットとして機能していました。 そのため、 マルチテナントSaaSソリューションへの移行とともに、 事前に構築された構成可能な統合テンプレートを提供する戦略にも移行しています。 そこで、Flow と PTC のチームは、

19:21 、これらの統合テンプレートの構築に注力したいと考えています。 ですから、 私たちが注目している統合パターンの例としては、 システム間の変更の調整などがあります。 たとえば、Windchill で変更を加えると、 ERP システムにも適切な変更が加えられる可能性があります。 もう 1 つは、 get instruction というユースケースです。

19:53 そのため、 これらは顧客が出発点として使用できるテンプレートとして提供され、その後、 組織のビジネスニーズに合わせて構成できるようになります。 大丈夫。それでは、 先ほど、 それらのテンプレートのいくつかを開発してリリースしようとしている新しいテンプレート機能について話しました。 そして、 実際に最初に注目するのは、ERP Connectorテンプレートです。 そのため、現在、フローを活用しない ERP コネクタに関するソリューションが Windchill とお客様の両方に提供されています。

20:31 そのソリューションをこのフローテクノロジーに基づくソリューションに置き換えることを検討しており、いくつかのDPTテンプレートも開発中です。 繰り返しになりますが、現在 DPT は古い ThingWorx フローテクノロジーを活用しており、 このアトラスフローソリューションにも移行する予定です。 ですから、 これらは私たちが中期的に取り組んでいることのいくつかであり、その後はもう少し長く見据えています。 また、 PLMとERPの統合にも注力しています。 そのため、今日はすでに SAP コネクタがあります。 いくつかの機能強化を行い、

21:04 また、 いくつかの新しいPTCコネクタの開発にも取り組んでおり、Vuforia、 ServiceMax、Onshape、 およびそれらのコネクタをお客様が活用できるようにする予定です。 そこで、 ワークフローをオンプレミスで実行できる機能に取り組んでいます。 ワークフローの作成は PTC SaaS Platform Atlas で行います。

21:35 これらのワークフローをエッジにデプロイして実際に実行できる機能を開発中です。 そのため、 これらのワークフロー内のデータはファイアウォールの内側にとどまることができます。 そのためのアーキテクチャをざっと見てみると、PTC Flow ポータルと ポータルは常にクラウド上にあり、Azure Iot Hub を活用すると、

22:06 また、 お持ちのどのオンプレミスシステムにも接続できます。 そのため、クラウドに Windchill plus があり、SAP がオンプレミスにある場合は、 Windchill SAP ワークフローをそのエッジデバイスにデプロイすれば、 すべての実行はエッジで行われます。