ビジネスプロセスエンジン
一般的な时、私达はすべてプログラミング式の开発を采用して、プログラミング式の开発の利点はとても明らかです:直接、高効率、自由で、もちろんその欠点もあって、その利点はちょうど相対的で、直接のため、いくつかの変化はすべてコードの上の修正を行います;効率的なため、いったん問題が発生すると、結果も深刻になり、自由なため、修正のリスクも大きい.
これは多くの大手企業がプロセス化開発を行っている重要な原因の一つであり、例えば、上海普元、Livebos、Justep、多くの有名な知らない会社が類似のプロセス化開発エンジンを持っており、プロセス化開発を通じて、コードの再利用性を強化し、ソフトウェア開発コストとテストコストを低減している.ソフトウェアの保守性を向上させ、メンテナンスコストを削減します.
Tinyフレームワークはこの方面にも独自の方案があり、Tinyは主にいくつかの方面の問題を考慮している.
a.コンポーネント拡張の利便性
コンポーネントの拡張の利便性とは、プロセスが実際に遊んでいるコンポーネントであり、コンポーネントの拡張が非常に困難である場合、プロセスエンジンの可用性に直接影響します.したがって、Tinyフレームワークのプロセスエンジンのコンポーネント構造は非常に簡単で、1つのインタフェース方法しかありません.プロセスコンポーネントの登録とロードも重要であり、プロセスコンポーネントを拡張する際に複雑な登録や構成プロセスが必要になる場合、プロセス拡張の利便性も大幅に低下します.Tinyフレームワークは、システムの実行環境間にプロセスコンポーネントを入れるだけで、プロセスコンポーネントの登録が完了し、プロセスで使用できるようになり、プロセスコンポーネントの拡張の利便性が大幅に向上します.b.プロセスのオブジェクト向け特性サポート
プロセスの指向性サポートとは、Tinyフレームワークにおいてプロセスがオブジェクト指向性を有することを意味する.プロセスは継承できます.これにより、複数のプロセスで重複する部分が得られ、親プロセスで定義できます.その後、サブプロセスは親プロセスを継承すればいいです.プロセスノードは上書きできます.すなわち、親プロセスでは空のノードを定義できますが、プロセスではフロー関係が定義されていますが、プロセスノードの実装はサブプロセスに残っています.
c.プロセスの編集性
プロセスの編集は便利で、簡単でなければならない.専門のプロセス編集ツールがあればもっといい.ないときは、普通のXmlエディタを使っても簡単に編集することができる.
d.プロセスの再入力性
一般的なプロセスエンジンは再入力できません.つまり、実行を開始し、終了ノードまで実行してから完了するしかありません.Tinyプロセスエンジンは、プロセスの再入力をサポートします.つまり、必ずしも開始ノードから実行されるとは限らず、任意のノードから実行することができます.このメカニズムはプログラムの論理に非常に大きな自由度を提供し,この特性を利用してページストリームエンジンやワークフローエンジンを容易に構築することができる.ビジネス・プロセス・エンジンでも、より大きな自由度が得られます.
プロセスの再入力性をサポートするため、本プロセス処理においては、現在のプロセスにおいて切り替えや転送を行うだけでなく、他のプロセスのノードにも流すことができる.これは業務処理やページ処理、プロセス処理において極めて大きな役割を果たすが、これも両刃の剣であり、このような柔軟な機能を提供するとともに、ビジネス・プロセスが複雑に見える場合もあります.そのため、制御はアーキテクチャまたはコア開発者が作成したほうがいいです.一般の開発者は具体的なビジネス・ポイントだけを開発すればいいです.
ほほほ、こんなにたくさん言って、みんなは理解してやはり比較的に抽象的かもしれませんが、それでは例を見てみましょう.
HelloWorldComponentのソースコードは次のとおりです.
すべてのコンポーネントがComponentInterfaceインタフェースを実装する必要があることがわかります
その実現論理から,「Hello,」に入力した名前を付けて環境変数のresultに入れることが分かる.
実行結果を次に示します.
a.デフォルト開始ノードで実行開始
b.指定ノードから実行
確かに実行して結果を返したように見えますが、その実行メカニズムはどうなっていますか??
実際、上記のフローは簡略化されたフローであり、Tinyフローエンジンのパラメータの一部は入力されず、約束通りに正しく実行されてもよいが、実際には完全に書かれている場合、例は以下のようになっている.
flowノードのプロパティの意味は、id、唯一のプロセスprivateContextを決定し、trueの場合、プロセスで単独でcontextを申請します.そうしないと、呼び出し元のcontextを共有します.これにより、環境変数の衝突問題extend-flow-idを効果的に回避できます.継承されたプロセスidは、非常に強力な機能です.バージョン番号は後述します.同じidのプロセスには複数のバージョンが存在し、アクセス時にバージョンを指定しないとデフォルトで最新バージョンnameが採用され、titleは英語、中国語名のみを説明するために使用され、理解しやすいだけです.default-node-idは、デフォルト実行ノード、すなわち、コンポーネントの実行が完了し、そのアイテム値が次の処理ノードを指定していない場合、デフォルトノードbegin-node-idを実行し、ノードend-node-idを開始し、終了ノードが指定していない場合、begin-node-idはデフォルトbegin、end-node-idはデフォルトend nodeノード:idは指定され、1つのプロセスでidは一意でなければならないことを示す.componentノードclass-nameは、組織実装クラス名propertiesがコンポーネントのプロパティリストpropertyのnameとvalueがコンポーネントのプロパティの値であることを指定するために使用されます.value、ここには文字列が入っていますが、実際には処理が非常に柔軟で、後で説明します.next-nodesとは、実行結果に基づいて後続処理を行うルールである.
next-node、具体的なルール、component-result、一致項目、正規表現をサポートし、ノード内のコンポーネントの実行結果を一致させ、一致に成功すればこのルールの次のノードを実行します.Exception-typeは例外のクラス名です.例外が発生し、ここで定義したタイプと一致する場合は、このルールの次のノードを実行します.
継承といえば、extend-flow-idプロパティで指定すれば、プロセス継承は非常に簡単です.継承はマルチ継承をサポートしません.すなわち、プロセスは1つのプロセスからのみ継承できますが、多層継承をサポートできます.すなわち、a>b>c>d.....実際の開発過程では、継承を複雑にしないでください.そうすれば、プログラムロジックをもっと理解しにくくなります.継承は実際にどのような役割を果たすのでしょうか.まず,いくつかの属性が継承され,またノード情報が継承される.簡単に言えば、両方あります.現在のプロセスは計算され、現在は計算されていません.親プロセスは計算されています.継承はどんなシーンに適用されますか??継承が業務処理に適用されるパターンは非常に似ており,中間処理環境が異なる場合のみである.例えば、A B C D---O----D-C-B-Aタイプの業務処理フローは、Oのみが異なり、他の処理モードはまったく同じである.この場合、継承方式を採用するのは非常に快適で、親フローを定義すれば、サブフローではO 1つのフローノードだけを定義すればよい.後でプロセス調整を統一して、親プロセスで調整すればいいです.例えば、flow aaは
flow bbは
プロセスbbもスムーズに実行でき、実行結果はHello,world
非常に重要なポイントの一つは、属性付与です.
属性付与が使いやすいかどうかは,フレームワークの使いやすさを決定する.
定数付与「1」は数値定数を表すことができます
aaは文字列定数がサポートできることを示し、環境変数が値を付与する
例えば、xxは環境変数からxxキー値をとるオブジェクトを表す
属性付与をサポートできます
例:xx.abcは環境変数xxをとる属性abcを表す
例:xx.abc.defは、環境変数xxの属性abcをとる属性defを表す
コンビネーション割り当てをサポート
例えば:${in:aa.abc.def}-${in:bb.cc.dd}
環境aaにおける属性abcの属性defに「-」を加えた環境変数bbにおけるccの属性を表すdd属性
属性の階層は制限されません.
また、値の取り方は、自己拡張もサポートされています.
たとえば、${in:xmlkey.aa}でも環境内のxmlkeyに対応するxmlノードのaa属性を取得できます.
だから、思いもよらなかったことしかできなかった.
応用開発と配置方式は、B/SとB/A/S、C/A/Sなどが典型的である.B/A/SおよびC/A/S方式では、AとBとCは別々に配置されているため、すべてのコンテンツがContextを介して伝達される必要がある.
分離型導入の場合は、要求された環境データをネットワークを介して渡す必要があります.
B/S環境でシステムを構築したい場合は,HTTP処理ラインを介してプロセス処理結果を同布で呼び出すことが望ましい.
また,プロセス処理のデータはRequest,RequestAttribute,Session,Cookieである場合があり,これらのデータCOPYを環境に移すと,実際には大きな性能消費がある.
本プロセスエンジンは、サービス方式による呼び出しをサポートしているか、短絡方式による呼び出しをサポートしている.
B/A/Sアーキテクチャの使用を推奨しますが、現在、多くの製品がB/Sアーキテクチャの下で実行されていることは否定できません.
しかし、これはプロセスエンジンにとって、RequestやSession、Cookieなどのコンテンツに直接アクセスしないため、統合された導入であっても、分離的な導入を妨げることなく、Contextのインタフェースを実現する必要があることを前提として、サービスの無状態特性を保証することができます.
まとめ:
Tinyのプロセスエンジンは、かなり強力な機能と拡張性を提供しており、上記は一部だけで、完全には説明されていないものもありますが、実際にはEL式など多くの高度な機能も提供されており、プロセス編成開発を期待するには、かなりのサポートがあります.
現在、Tinyフレームワークでは、ビジネスプロセスの編成およびページプロセスの編成がこのエンジンに基づいて構築されており、応用効果は非常に良好である.将来的には、ワークフローエンジンが構築されます.
これは多くの大手企業がプロセス化開発を行っている重要な原因の一つであり、例えば、上海普元、Livebos、Justep、多くの有名な知らない会社が類似のプロセス化開発エンジンを持っており、プロセス化開発を通じて、コードの再利用性を強化し、ソフトウェア開発コストとテストコストを低減している.ソフトウェアの保守性を向上させ、メンテナンスコストを削減します.
Tinyフレームワークはこの方面にも独自の方案があり、Tinyは主にいくつかの方面の問題を考慮している.
a.コンポーネント拡張の利便性
コンポーネントの拡張の利便性とは、プロセスが実際に遊んでいるコンポーネントであり、コンポーネントの拡張が非常に困難である場合、プロセスエンジンの可用性に直接影響します.したがって、Tinyフレームワークのプロセスエンジンのコンポーネント構造は非常に簡単で、1つのインタフェース方法しかありません.プロセスコンポーネントの登録とロードも重要であり、プロセスコンポーネントを拡張する際に複雑な登録や構成プロセスが必要になる場合、プロセス拡張の利便性も大幅に低下します.Tinyフレームワークは、システムの実行環境間にプロセスコンポーネントを入れるだけで、プロセスコンポーネントの登録が完了し、プロセスで使用できるようになり、プロセスコンポーネントの拡張の利便性が大幅に向上します.b.プロセスのオブジェクト向け特性サポート
プロセスの指向性サポートとは、Tinyフレームワークにおいてプロセスがオブジェクト指向性を有することを意味する.プロセスは継承できます.これにより、複数のプロセスで重複する部分が得られ、親プロセスで定義できます.その後、サブプロセスは親プロセスを継承すればいいです.プロセスノードは上書きできます.すなわち、親プロセスでは空のノードを定義できますが、プロセスではフロー関係が定義されていますが、プロセスノードの実装はサブプロセスに残っています.
c.プロセスの編集性
プロセスの編集は便利で、簡単でなければならない.専門のプロセス編集ツールがあればもっといい.ないときは、普通のXmlエディタを使っても簡単に編集することができる.
d.プロセスの再入力性
一般的なプロセスエンジンは再入力できません.つまり、実行を開始し、終了ノードまで実行してから完了するしかありません.Tinyプロセスエンジンは、プロセスの再入力をサポートします.つまり、必ずしも開始ノードから実行されるとは限らず、任意のノードから実行することができます.このメカニズムはプログラムの論理に非常に大きな自由度を提供し,この特性を利用してページストリームエンジンやワークフローエンジンを容易に構築することができる.ビジネス・プロセス・エンジンでも、より大きな自由度が得られます.
プロセスの再入力性をサポートするため、本プロセス処理においては、現在のプロセスにおいて切り替えや転送を行うだけでなく、他のプロセスのノードにも流すことができる.これは業務処理やページ処理、プロセス処理において極めて大きな役割を果たすが、これも両刃の剣であり、このような柔軟な機能を提供するとともに、ビジネス・プロセスが複雑に見える場合もあります.そのため、制御はアーキテクチャまたはコア開発者が作成したほうがいいです.一般の開発者は具体的なビジネス・ポイントだけを開発すればいいです.
ほほほ、こんなにたくさん言って、みんなは理解してやはり比較的に抽象的かもしれませんが、それでは例を見てみましょう.
<flow id="1000" name="Hello">
<nodes>
<node id="begin">
<component class-name="org.tinygroup.flow.HelloWorldComponent">
<properties>
<property name="name" value="world" />
</properties>
</component>
</node>
</nodes>
</flow>HelloWorldComponentのソースコードは次のとおりです.
public class HelloWorldComponent implements ComponentInterface {
String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public void execute(Context context) {
context.put("result", String.format("Hello, %s", name));
}
}すべてのコンポーネントがComponentInterfaceインタフェースを実装する必要があることがわかります
その実現論理から,「Hello,」に入力した名前を付けて環境変数のresultに入れることが分かる.
実行結果を次に示します.
a.デフォルト開始ノードで実行開始
Context context = new ContextImpl();
flowExecutor.execute("1000", context);
assertEquals("Hello, world", context.get("result"));b.指定ノードから実行
Context context = new ContextImpl();
flowExecutor.execute("1000","begin", context);
assertEquals("Hello, world", context.get("result"));確かに実行して結果を返したように見えますが、その実行メカニズムはどうなっていますか??
実際、上記のフローは簡略化されたフローであり、Tinyフローエンジンのパラメータの一部は入力されず、約束通りに正しく実行されてもよいが、実際には完全に書かれている場合、例は以下のようになっている.
<flow id="1000" version="1.0" privateContext="false" extend-flow-id="" name="Hello" title=" " default-node-id="end" begin-node-id="begin" end-node-id="end" enable="true">
<description>some thing....</description>
<nodes>
<node id="begin">
<component class-name="org.tinygroup.flow.HelloWorldComponent">
<properties>
<property name="name" value="world"/> </properties>
</component>
<next-nodes>
<next-node exception-type="java.lang.Exception" next-node-id="end"/>
</next-nodes>
</node>
</nodes>
</flow>flowノードのプロパティの意味は、id、唯一のプロセスprivateContextを決定し、trueの場合、プロセスで単独でcontextを申請します.そうしないと、呼び出し元のcontextを共有します.これにより、環境変数の衝突問題extend-flow-idを効果的に回避できます.継承されたプロセスidは、非常に強力な機能です.バージョン番号は後述します.同じidのプロセスには複数のバージョンが存在し、アクセス時にバージョンを指定しないとデフォルトで最新バージョンnameが採用され、titleは英語、中国語名のみを説明するために使用され、理解しやすいだけです.default-node-idは、デフォルト実行ノード、すなわち、コンポーネントの実行が完了し、そのアイテム値が次の処理ノードを指定していない場合、デフォルトノードbegin-node-idを実行し、ノードend-node-idを開始し、終了ノードが指定していない場合、begin-node-idはデフォルトbegin、end-node-idはデフォルトend nodeノード:idは指定され、1つのプロセスでidは一意でなければならないことを示す.componentノードclass-nameは、組織実装クラス名propertiesがコンポーネントのプロパティリストpropertyのnameとvalueがコンポーネントのプロパティの値であることを指定するために使用されます.value、ここには文字列が入っていますが、実際には処理が非常に柔軟で、後で説明します.next-nodesとは、実行結果に基づいて後続処理を行うルールである.
next-node、具体的なルール、component-result、一致項目、正規表現をサポートし、ノード内のコンポーネントの実行結果を一致させ、一致に成功すればこのルールの次のノードを実行します.Exception-typeは例外のクラス名です.例外が発生し、ここで定義したタイプと一致する場合は、このルールの次のノードを実行します.
継承といえば、extend-flow-idプロパティで指定すれば、プロセス継承は非常に簡単です.継承はマルチ継承をサポートしません.すなわち、プロセスは1つのプロセスからのみ継承できますが、多層継承をサポートできます.すなわち、a>b>c>d.....実際の開発過程では、継承を複雑にしないでください.そうすれば、プログラムロジックをもっと理解しにくくなります.継承は実際にどのような役割を果たすのでしょうか.まず,いくつかの属性が継承され,またノード情報が継承される.簡単に言えば、両方あります.現在のプロセスは計算され、現在は計算されていません.親プロセスは計算されています.継承はどんなシーンに適用されますか??継承が業務処理に適用されるパターンは非常に似ており,中間処理環境が異なる場合のみである.例えば、A B C D---O----D-C-B-Aタイプの業務処理フローは、Oのみが異なり、他の処理モードはまったく同じである.この場合、継承方式を採用するのは非常に快適で、親フローを定義すれば、サブフローではO 1つのフローノードだけを定義すればよい.後でプロセス調整を統一して、親プロセスで調整すればいいです.例えば、flow aaは
<flow id="aa" name="aa">
<nodes>
<node id="begin">
<next-nodes>
<next-node component-result="begin" next-node-id="hello"/>
</next-nodes>
</node>
<node id="hello">
<component class-name="org.tinygroup.flow.HelloWorldComponent">
<properties>
<property name="name" value="world"/>
</properties>
</component>
<next-nodes>
<next-node next-node-id="end"/>
</next-nodes>
</node>
</nodes>
</flow>flow bbは
<flow id="bb" name="bb" extend-flow-id="aa">
<nodes>
<node id="hello">
<component class-name="org.tinygroup.flow.HelloWorldComponent">
<properties>
<property name="name" value="world" />
</properties>
</component>
</node>
</nodes>
</flow>プロセスbbもスムーズに実行でき、実行結果はHello,world
非常に重要なポイントの一つは、属性付与です.
属性付与が使いやすいかどうかは,フレームワークの使いやすさを決定する.
定数付与「1」は数値定数を表すことができます
aaは文字列定数がサポートできることを示し、環境変数が値を付与する
例えば、xxは環境変数からxxキー値をとるオブジェクトを表す
属性付与をサポートできます
例:xx.abcは環境変数xxをとる属性abcを表す
例:xx.abc.defは、環境変数xxの属性abcをとる属性defを表す
コンビネーション割り当てをサポート
例えば:${in:aa.abc.def}-${in:bb.cc.dd}
環境aaにおける属性abcの属性defに「-」を加えた環境変数bbにおけるccの属性を表すdd属性
属性の階層は制限されません.
また、値の取り方は、自己拡張もサポートされています.
たとえば、${in:xmlkey.aa}でも環境内のxmlkeyに対応するxmlノードのaa属性を取得できます.
だから、思いもよらなかったことしかできなかった.
応用開発と配置方式は、B/SとB/A/S、C/A/Sなどが典型的である.B/A/SおよびC/A/S方式では、AとBとCは別々に配置されているため、すべてのコンテンツがContextを介して伝達される必要がある.
分離型導入の場合は、要求された環境データをネットワークを介して渡す必要があります.
B/S環境でシステムを構築したい場合は,HTTP処理ラインを介してプロセス処理結果を同布で呼び出すことが望ましい.
また,プロセス処理のデータはRequest,RequestAttribute,Session,Cookieである場合があり,これらのデータCOPYを環境に移すと,実際には大きな性能消費がある.
本プロセスエンジンは、サービス方式による呼び出しをサポートしているか、短絡方式による呼び出しをサポートしている.
B/A/Sアーキテクチャの使用を推奨しますが、現在、多くの製品がB/Sアーキテクチャの下で実行されていることは否定できません.
しかし、これはプロセスエンジンにとって、RequestやSession、Cookieなどのコンテンツに直接アクセスしないため、統合された導入であっても、分離的な導入を妨げることなく、Contextのインタフェースを実現する必要があることを前提として、サービスの無状態特性を保証することができます.
まとめ:
Tinyのプロセスエンジンは、かなり強力な機能と拡張性を提供しており、上記は一部だけで、完全には説明されていないものもありますが、実際にはEL式など多くの高度な機能も提供されており、プロセス編成開発を期待するには、かなりのサポートがあります.
現在、Tinyフレームワークでは、ビジネスプロセスの編成およびページプロセスの編成がこのエンジンに基づいて構築されており、応用効果は非常に良好である.将来的には、ワークフローエンジンが構築されます.