情報システムのカスタマイズについて

当社の主な活動は、企業情報システムの開発です。 カスタムメイドのシステムに加えて、2つの複製製品を作成しています。 もちろん、可能な限り便利で機能的な製品を作ろうとしています。 ただし、実際には、各ビジネスには独自の特性があり、常にシステムの標準機能に対応する準備ができているわけではありません。 特定のクライアント向けのソリューションを完成させるタスクと、そのさらなるサポートがあります。 拡張可能な製品のアーキテクチャを整理するためのアプローチは何ですか？ 開発中にどのような問題が発生する可能性がありますか？ 私たちは何をしましたか？ 以下のすべてについて。

可能なアプローチ

まず、「拡張プロジェクト」または単に「拡張」によって、特定の顧客向けに変更を加えた製品を呼び出すことを明確にします。 次に、製品を拡張するための可能なアプローチのいくつかを見てみましょう。

どうやってやるの

ECM（またはより一般的な用語で言うと、電子文書管理システム、EDMS） TESISとタクシービジネスSherlockを自動化するシステムという2つの複製製品を市場に投入しました。 最初から明らかでした。特定のクライアントに最も便利なシステムを提供するためには、製品開発が必要になるため、製品は容易に拡張可能なアーキテクチャに基づいている必要があります。



新しい拡張機能の作業を開始するとき、私たちはこのプロジェクトがどの「モンスター」（言葉の意味では）に成長できるかを推測することさえしませんでした。 よくあるのは、小さなカスタマイズとして始まったものが、ほぼ完全に書き直されたビジネスプロセスと、画面の半分の追加ロジックで終わることです。 さらに、この製品は新しい機能で拡張することができます。これは独立したシステムには十分です。 例として、大規模な分散企業向けのTESISの拡張プロジェクトでは、財務の自動化、従業員の有効性の評価、およびいくつかのより複雑なモジュールが登場しました。



さまざまな要件、その量、および予測不能性により、上記のいずれの方法も使用できませんでした。 その上、製品バージョンはかなり定期的に公開されます。 これにより、拡張プロジェクトを製品の新しいバージョンに簡単に転送できることが要求されます。



拡張機能の作成とサポートの問題をどのように解決しますか？

拡張プロジェクト

当社のプロジェクトのほとんどは、CUBAプラットフォームを使用して作成されています。 以前の記事の 1つですでに書いています。 拡張プロジェクトの編成方法を理解するには、まずプラットフォーム自体のデバイスを扱う必要があります。



つまり、CUBAは一連のモジュールであり、それぞれが特定の機能を提供します。

• キューバ-アプリケーションのコア。インフラストラクチャ全体、ビジネスロジックを整理するためのツール、視覚コンポーネントのライブラリ、セキュリティサブシステムなどが含まれます。
• レポート-レポート生成サブシステム
• fts-全文検索サブシステム
• チャート-チャート出力サブシステム
• ワークフロー-ビジネスプロセス管理サブシステム
• ccpayments-クレジットカードサブシステム

各サブシステムには、ビジネスロジックを備えた永続的なエンティティ、画面、およびサービスを含めることができます。



新しいプロジェクトを作成するとき、機能が必要なプラットフォームのベースモジュールへの依存関係は、ビルドスクリプトに記述されます。 その後、接続されたモジュールのエンティティ、画面、およびサービスを使用して、プロジェクトの実装を開始します。 物理的には、プラットフォームモジュールはjarファイルであり、サーバーにインストールされるプロジェクトは通常のJava Webアプリケーションです。



プラットフォーム上で既存の製品を拡張する必要がある場合、これを行います。新しいプロジェクトを作成しますが、ビルドスクリプトでは、プラットフォームモジュールではなく拡張可能な製品への依存を示します。 製品自体は、実際には開発プラットフォームとして機能します。





これで、拡張プロジェクト内で、新しいドメインモデルオブジェクトを作成し、CUBAプラットフォーム上の最も一般的なプロジェクトのように新しいユーザーインターフェイスを記述できます。 開発者は、下位モジュールのすべての機能を引き続き利用できます。



最も明らかな利点は、すべての新しいロジックが個別の拡張プロジェクトに保存されることです。 現在の拡張機能の一部として、いつ何を書いたかを常に確認できます。 このアプローチは、プラグインアーキテクチャとEAVのように、開発者を新しい機能の種類に制限するものではありません。



拡張機能を製品の新しいバージョンに変換するプロセスは次のとおりです。

• ビルドスクリプトで製品の新しいバージョンを指定し、拡張機能を再構築します。
• 拡張機能が安定した製品APIのみを使用している場合、それだけです-高度な製品を起動してください。
• 展開したポイントで製品が大幅に変更された場合、拡張コードを変更する必要がある場合があります。 原則として、これはまれにしか発生せず、問題を特定するのは簡単です。 バグ修正製品リリースは常に拡張機能と互換性があります。

拡張機能では、新しいエンティティ、ビジネスロジック、およびそれらの画面を簡単に作成できることは明らかです。 しかし、すでに製品にあるものを変更するにはどうすればよいですか？ たとえば、製品エンティティにフィールドを追加して、既存の画面に表示しますか？

ベースプロダクトエンティティに新しい属性を追加する

タスクを自分用に定義します。ベース製品のUser



エンティティで、住所を保存するフィールドを追加する必要があります。 このような要件は、おそらくお客様の間で最も一般的です。 プラットフォームが上記の動的属性モデルをサポートしていることをすぐに言う必要がありますが、実際にはこのオプションはほとんど使用されません-データサンプリング速度とレポートの容易さは、ほとんどの場合重要な要件です。

実際には、属性を追加する代替方法について。 ORMプラットフォームとして、OpenJPAが使用されます。 製品のエンティティ宣言は次のとおりです。

 @Entity(name = "product$User") @Table(name = "PRODUCT_USER") public class User extends StandardEntity { @Column(name = "LOGIN") protected String login; @Column(name = "PASSWORD") protected String password; //getters and setters }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、これはエンティティの標準的な説明であり、JPAのテーブルおよびデータベース列へのマッピングです。



拡張プロジェクトにエンティティー継承を作成します。

 @Entity(name = "ext$User") @Extends(User.class) public class ExtUser extends User { @Column(name = "ADDRESS", length = 100) private String address; public String getAddress() { return address; } public void setAddress(String address) { this.address = address; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

継承メカニズムは、最も重要な@Extends



注釈を除き、OpenJPAの標準です。 ExtUser



クラスがUserクラスの代わりに普遍的に使用されることを宣言するのは彼女です。



これで、 User



エンティティを作成するすべての操作で、拡張エンティティのインスタンスが作成されます。

 User user = metadata.create(User.class); //  ExtUser
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データベースからのデータ抽出操作も、新しいエンティティのインスタンスを返します。 たとえば、ベース製品では、名前によるユーザー検索サービスが返され、次のJPQLクエリの結果が返されます。

 select u from product$User u where u.name = :name
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

@Extends



アノテーションがなければ、出力にUser



オブジェクトのコレクションがあり、 ExtUser



からアドレスを取得するには、データベースから以前のリクエストの結果を再読み込みする必要があります。 しかし、 @Extends



アノテーションによって提供される再定義情報を使用して、プラットフォームメカニズムはリクエストを予備的に変換し、拡張ExtUser



エンティティのオブジェクトのコレクションをExtUser



ます。 さらに、他のエンティティがUser



へのリンクを持っている場合、拡張機能が接続されると、これらのリンクはソースコードを変更せずにExtUser



型のオブジェクトを返します。



エンティティが再定義されます。 ここで、新しいフィールドをユーザーに表示するといいでしょう。



プラットフォーム画面は、XML + Javaの束です。 XMLは宣言的にUIを記述し、Javaコントローラーはイベントに対する反応を決定します。 Javaコントローラーを再定義しても特別な問題が発生しないことは明らかですが、XML拡張機能を使用すると少し複雑になります。 User



エンティティにaddress



フィールドを追加して、前の例に戻りましょう。

最も単純な画面のレイアウトの説明は次のようになります。

 <window datasource="userDs" caption="msg://caption" class="com.haulmont.cuba.gui.app.security.user.edit.UserEditor" messagesPack="com.haulmont.cuba.gui.app.security.user.edit" > <dsContext> <datasource id="userDs" class="com.haulmont.cuba.security.entity.User" view="user.edit"> </datasource> </dsContext> <layout spacing="true"> <fieldGroup id="fieldGroup" datasource="userDs"> <column width="250px"> <field id="login"/> <field id="password"/> </column> </fieldGroup> <iframe id="windowActions" screen="editWindowActions"/> </layout> </window>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UserEditorスクリーンコントローラーへのリンク、データソース宣言（datasource）、エンティティフィールドを表示するfieldGroupコンポーネント、および標準アクション「OK」および「Cancel」（windowActions）のあるフレームが表示されます。



拡張プロジェクトで基本画面コードを複製したくないので、プラットフォームにXML画面記述子を継承する機能を追加しました。 これは、基本プロジェクトからの画面継承者のようです。

 <window extends="/com/haulmont/cuba/gui/app/security/user/edit/user-edit.xml"> <layout> <fieldGroup id="fieldGroup"> <column> <field id="address"/> </column> </fieldGroup> </layout> </window>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

祖先画面は祖先（extends属性）を示し、ベース画面に追加または再定義する必要があるコンポーネントのみを説明します。 基本画面の識別子を使用して、構成ファイルで画面を宣言するだけです。

 <screen id="sec$User.edit" template="com/sample/sales/gui/extuser/extuser-edit.xml"/>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果：

ビジネスロジックのオーバーライド

機能の再定義に関しては、ここではすべてが非常に簡単です。 プラットフォームインフラストラクチャはSpringに実装されています。 したがって、ビジネスロジックを持つサービスレイヤーは、スプリング駆動型Beanです。 フレームワークによって提供される拡張機能は、必要なビジネスロジックを再定義するのに十分以上です。 これを明確に示すために、再び小さな例を示します。 基本製品の中間層に、価格計算を実行するコンポーネントがあると仮定します。

 @ManagedBean("product_PriceCalculator") public class PriceCalculator { public void BigDecimal calculatePrice() { //price calculation } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

拡張プロジェクトの価格設定アルゴリズムを置き換えるために、2つの簡単な手順を実行します。



再定義されたコンポーネントの継承を作成します。

 public class ExtPriceCalculator extends PriceCalcuator { @Override public void BigDecimal calculatePrice() { //modified logic goes here } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

基本製品のbin識別子を使用して、Spring構成ファイルにクラスを登録します。

 <bean id="product_PriceCalculator" class="com.sample.extension.core.ExtPriceCalculator"/>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、Springコンテナは常にExtPriceCalculatorのインスタンスを返します。

トピックの再定義

エンティティ、画面のコンポーネント、およびビジネスロジックの変更により、私たちは把握しました。 次の行は視覚的なテーマです。



プラットフォームを使用して作成された画面は、Webおよびデスクトップクライアントで機能します。 現時点では、主にWebクライアントを使用しているため、トピックのカスタマイズについては、それらを検討します。



Web UIを実装するために、人気のあるVaadinフレームワークを選択しました。 Vaadinでは、SCSSに関するトピックを説明できます。 新しいSCSSテーマのスタイルの説明は、純粋なCSSよりも何倍も楽しいものです。 多くのパラメーターを変数に入れることで、テーマの作成プロセスの時間をさらに短縮しました。



開発スタジオを使用して、2回のクリックで新しいトピックの空白が作成されます。 新しいテーマはプラットフォームの基本テーマのスタイルをインポートします。開発者は必要なスタイルと変数を再定義するだけです。 多くの顧客は、情報システムを会社のコーポレートカラーで見たいと考えています。 トピックを拡張するためのアプローチにより、簡単にこれを実現できます。



拡張プロジェクトでは、開発者は新しいビジュアルコンポーネントを接続できます。 多数の既製のコンポーネントがVaadinアドオンリポジトリで利用可能です。 必要なコンポーネントがそこに見つからなかった場合は、自分で作成できます。



さまざまな視覚テーマの例：

おわりに

私たちのアプローチがあなたにとって興味深いと思われる場合は、 CUBAプラットフォームを自分で試すことができます。 プラットフォームで製品を作成すると、記載されている方法で製品を自動的にカスタマイズできます。 フィードバックとコメントを常に歓迎します！



PSタイトル写真の作者はイリヤ・バルラモフです。 彼のブログでさらに豪華なパキスタントラックを見つけることができます。