FAQ

 イノルールズ社の「教育・研修プログラム」には、以下の2コースが用意されています。

①有償の「InnoRules R＆D教育サービス」

②無償の「BRMSハンズオン教育サービス」

「①InnoRules R＆D教育サービス」は、製品トレーニングと、貴社が調査研究を目的とする実行環境のご提供の他、貴社ご担当者様がスムーズにルール登録を行えるように育成するコンサルティングサービスとなります。

「②BRMSハンズオン教育サービス」 は、2～3時間を目途に自習形式で完了できるコースであり、製品機能と使い方の理解を進めることができます。

■ InnoRulesにて作成したルールは、汎用的なWebサービスプロトコル（ RestFul）を利用して、簡単に呼び出すことができます。

■ 呼出元アプリケーションの実装言語の最適化したRule APIを提供しており、そのRule APIを利用して、ルールを呼び出すこともできます。

■ 連携の実績

　連携テスト、本番導入含めた実績を以下に示します

【RPA】WinActor (REST通信) 、BizRobo (REST通信)、UiPath (REST通信)

【ETL】Asteria Warp (REST通信/Rule API利用)

【ERP】SAP (Rule API利用)

【超高速開発ツール】Genexus (SOAP通信)、WebPerformer (Rule API利用)、Wagby (Rule API利用)、楽々フレームワーク (Rule API利用)

メジャーバージョンがリリースされる場合の旧バージョンへの対応は以下の通りです。

■ EOL(End of Life) : 新規バージョンリリース後の6ヶ月後に販売活動終了

■ EOS(End of Support) : EOL終了後の5年間、標準保守サービスを提供

■ アナウンス：6ヶ月以前に代理店/顧客に通知します。

基本的には、サポート期間を過ぎた製品につきましては、通常のサポート対象外となります。

そのため、製品のサービス提供期間内にアップグレードをご検討いただくようお願いしております。

ただし、やむを得ずサポート期間を過ぎた製品を継続してご利用いただく必要がある場合には、個別にご相談を承りますので、お気軽にお問い合わせください。

InnoRules製品のバージョンアップには、マイナーバージョンアップ（例：v7.2 → v7.3）とメジャーバージョンアップ（例：v7.x → v8.x）があります。

• マイナーバージョンアップ

マイナーバージョンアップは、主にバグ修正や軽微な機能追加・改善など、製品仕様に影響を与えない範囲で行われるアップデートです。

弊社より、無償でパッチファイルおよび適用手順書をご提供いたしますので、お客様にて必要に応じてパッチの適用をご判断いただきます。

• メジャーバージョンアップ

メジャーバージョンアップでは、ルールリポジトリやルールAPIの仕様変更など、製品仕様に変更が生じる場合があります。

仕様変更に伴いルールデータの移行が必要となる場合は、弊社より無償で移行ツールをご提供いたします。

なお、弊社にて移行作業を代行させていただく場合は、有償サービスとして承っております。

マイナーバージョンアップは、おおよそ1〜2年に一度の頻度で実施しております。

メジャーバージョンアップは、概ね5〜7年に一度のペースで行われます。

なお、パッチにつきましては、通常対応・緊急対応を含め、必要に応じて随時発行しております。

製品の脆弱性に関する情報につきましては、弊社ウェブサイトおよび保守サービスを通じて随時ご案内しております。 

保守対応におけるお客様の一次窓口は、弊社の販売代理店となります。

弊社は、販売代理店を技術的にサポートする立場となります（以下同様）。

• 弊社の販売代理店向けのサポート内容

サポート体制は、平日9:00～17:00の時間帯で稼働しております。

サポートの受付はメールにて行っており、受付自体は24時間対応可能です（サポート対応は営業時間内に行います）。

なお、緊急性の高い障害などが発生した場合には、緊急連絡用の電話窓口を設けることも可能です。

製品自体にはリモートアクセス機能は含まれておりません。

そのため、御社ネットワークへアクセス可能となる手段（VPN接続等）をご提供いただいた上で、弊社サポートメンバーがSSHクライアント等を利用して実機へアクセスさせていただく形となります。

はい。上記記載のすべてのDBの形式に対応できます。

無料のハンズオン(2時間)を受講いただいた上で、期間が１か月の評価版ライセンス(無償)をお貸出しいたします。メール（sales@innorules.co.jp）にてお問合せください。

エクスプローラーのような形式でフォルダ毎にルールをカテゴライズすることでルールの整理が容易に行えます。
類似ルール作成時にも有効です。またルールのメタ情報としてメインルールと共通ルールの指定ができ専用のタブで表示・確認することができます。

必要なデータが、クラウド・オンプレ・Mainframeなどルールエンジンの外部DBにある時に、InnoRulesにDBルールを作成し、JDBC経由で参照することもできます。

その時の性能は、ネットワーク性能、DB性能などルールエンジン外部の性能要因に左右されますので、もし性能が良くない場合はアーキテクチャを再検討する必要があります。

ルールが論理的に正しいかをチェックできます。

（例）
条件に矛盾あり/条件重複/曖昧な条件を含むルール/実行されないデッドルールの検出など

クライアントツール（Rule Builder）の各機能にExcel連携機能があり、それらを利用してExcelに情報を抽出可能です。また、ルールビルダーとExcel間でルールのコピー＆ペーストが可能です。多重テストの際にExcelからのデータ取込も可能です。

使いやすいデプロイ機能がルールビルダーに装備されています。開発済のルールをテスト環境にデプロイすることを、製品上では「ルールをテスト環境へ移管する」と呼んでいます。移管には次の特長があります。

• 次系に移管されると自動的に最新ルールが適用されるので、ルールサーバを再起動する必要はありません（Hot Deploy）。
• 承認プロセスを経て移管するので、いつ誰が承認して移管したのかが履歴として残ります。
• 移管履歴から移管時のルールの内容を参照できます。
• 権限管理機能により、特定ユーザのみが本番システムへ移管できるように制限をかけることができます。
• 移管プロセスのアクションが履歴管理されるので、内部統制による業務把握が容易になります。

InnoRules で移管を行うと移管履歴情報で一元管理され、ルール毎にどの環境にデプロイされたかを把握することができます。

（補足）InnoRulesは、ノンコーディングツールなので、作成されるルールからPGMソースは生成しません。従って、外部のデプロイツールとの連携は不要です。また、作成されたルールは、ルールリポジトリで管理され、実行時にルールエンジンにロードされで実行されます。

ルールを複数人で開発することは可能です。1つのルールを複数の担当者が同時に開発したり、上位・下位のルールを同時に複数の担当者が開発することもできます。InnoRulesでは、ルールリポジトリを複数のルール開発者が共有しながらルール開発を行うことを想定しています。

InnoRulesには、楽観的な排他制御機能があります。

同じルールを複数人が編集して保存した場合には、当人が保存する際に他人によって保存されている旨の警告を表示します。そして、他人が変更した内容を照会することができます。このような方式で同時に編集したルールの競合を解消しています。

InnoRulesではユーザ毎にルール開発権限、ルール運用権限、ルール管理権限などの権限を付与することができます。

ルール開発者は会社の業務部門ごとにアクセス制限をかけることもできます。（例：新契約部門が変更可能なルールを限定する）

ルールの変更承認はルールビルダーを使用して、変更したルールを別のルールシステム（例：開発環境=>テスト環境）へ移管するタイミングで実行できます。

（補足）InnoRulesは、ノンコーディングツールなので、作成されるルールからPGMソースは生成しません。このように、外部のデプロイツールとの連携は不要であることから、既存の承認管理ツールとの連携も不要になります。

ルールビルダーは業務部門が内製化するためのツールとして「使いやすい」「分かりやすい」コンセプトで開発された製品です。特長は、シンプルな項目登録、分かりやすいルール表現、業務仕様と親和性が高いルールテンプレート、実行状況がすぐに把握できるトレース機能などになります。

弊社のお客様では業務部門主導で内製化を実現されているケースが多いです。

他システムとのI/F開発容易にするために各種開発言語用のAPI機能やWebサービス(REST)連携機能を提供しています。また、I/F開発を支援するためのアシスタント機能もあります。それらの機能を使って各種言語(COBOL、C、Java等)で開発されたアプリケーションやパッケージシステム(SAP、CRM、BPM、Excel等)との接続実績が多数あります。

ルール呼出方法がRule APIを利用する場合は、APIを提供しますが、REST方式を利用する場合はドキュメントのみです。REST方式でも、共通処理機能を実装したRESTクライアントライブラリを開発するケースもあります。RESTクライアントライブラリはIR代理店またはお客様側で開発するものになります。

InnoProductは商品データを商品リポジトリ（RDB）に格納しており、業務アプリケーションからもアクセス可能ですが、業務アプリケーションが直接参照することを推奨していません。

推奨しない理由は、

①業務アプリケーションが商品リポジトリから商品データを取得するためには、商品リポジトリのテーブル定義を理解する必要があります。ルールを利用する場合、PFキャッシュ用ユーザ定義関数が使えるので簡単に商品情報が取得できるので、業務アプリケーションが直接商品リポジトリにアクセスするよりルールを経由して商品データを取得した方が生産性が良いです。

②業務アプリケーションから商品リポジトリへ直接アクセスする場合、PFキャッシュが使えないため、ルール利用より相対的に性能が劣ります。

③商品リポジトリに性能問題が発生した時に、利用元が複数であれば、原因特定が困難になります。

④商品リポジトリの仕様変更が発生した場合、影響分析範囲や修正範囲が大きくなります。

⑤業務アプリケーションが商品リポジトリのデータを直接更新する恐れがあります。

• 技術的な面

InnoRulesで作成したルールはWebサービスで呼び出すことができるので、Webサービス呼び出し機能があるBPMからInnoRules呼出が可能です

• 実績面

ある金融会社の事例です。

CamundaからInnoRulesをRESTで呼び出した実績があります。

 例）このルールは夜間のみ実施、このルールは2022/3/1から有効など

実行のタイミングは呼び出し元のアプリケーションに依存します。

（時間の概念は製品にありません）

呼び出したときに、実行対象となるルールの制御はバージョン機能で実現できます。

（例）：ルールAのバージョンが2022/3/1と2022/4/1の2つある場合

アプリケーションがルール呼出時のパラメータに実行基準日付を指定します。

実行基準日付より前で直近のバージョンのルールが実行されます。

この場合、実行基準日付が2022/3/10であれば、ルールA（Ver2022/3/1)が実行対象となります。

アクションはルール呼び出し元へ結果を返却するのみです。

DB書き込みやメール送信などのアクションは呼び出し元が行います。

デフォルトでは製品にユーザID/PW登録して、認証する仕組みですが、製品をカスタマイズすることで外部のAD/LDAPと連携出来ます。

SSL通信が可能です。TLS1.2、TLS1.3に対応しています。※証明書の利用が可能

製品機能としてはスレッドプール、DBコネクションプール機能を使い、ルール実行のリクエストに対して流量制限を行います。サービス単位の流量制限をするためには、API GWとの連携が必要です。

Webサービス（REST）でルールを呼び出すことができるので、Webサービス呼出機能があるAPI-GWと連携することが出来ます。

InnoRulesのルールエンジンはJavaルールエンジンですので、Javaが稼働できるサーバ環境であれば、ルールエンジンを稼働させることが可能です。

• オンプレ/Openシステムで利用する方法

① 同じJVM上にアプリとルールエンジンを稼働させる場合

Rule APIを利用する方法ではアプリケーション言語がJavaの場合は、最大の性能を出すことができます。

② アプリとルールエンジンがリモート環境で稼働させる場合

Webサービスを利用する方法では、RESTを利用してルールを呼び出すことができます。

• クラウドで利用する方法

①クラウドにルールサーバー環境を構築して稼働させる場合

サーバ上にJavaとルールリポジトリを構築、InnoRules製品をインストールしてルールエンジンを稼働させる方法です。アーキテクチャ設計・サーバ構築・管理・運用の検討が必要です。

②サーバーレス環境で稼働させる場合

AWS Lambdaのようにサーバーレズ環境のJava Runtimeを利用してルールエンジンを稼働させる方法があります。冗長化、スケーリングをクラウドが担当するので、サーバ構築・管理・運用の時間とコストが節約できます。（※ルール実行機能のみサーバーレス利用可能。ルール作成機能はサーバが必要）

InnoRulesのルールエンジンはJavaで開発されたJavaルールエンジンですので、Mainframe上で稼働させることはできません。外部サーバにJavaをインストールしてJavaルールエンジンを稼働させて、Mainframeからルールを呼び出す方式になります。

Mainframeからルールを利用する場合、①Rule APIを利用する方法、②Webサービスを利用する方法があります。

• Rule APIを利用する方法

C言語のRule APIをInnoRulesが提供します。Rule APIをMainframe上でコンパイルしCOBOLがRule APIを利用してルールを呼び出すことが可能です。

•  Webサービスを利用する方法

COBOLがSOAPかRESTを利用して、ルールを呼び出すこともできます。

性能はRule APIが若干良いですが、Rule APIの場合MF上コンパイル作業が必要であること（費用面）、COBOLにRule API依存コードを記述する必要があること（密結合）もあり、汎用プロトコルを利用できるWebサービスをお勧めします。

性能については、性能要件に合う十分な性能を満たすため、オンライン処理の場合はルールサーバのスケーリングを、バッチ処理の場合は並列処理で対応することが可能です。

金融会社を含めて多数あります。

性能要件などシステム要件により、必要スペックが変わるので、予め推奨するスペックはございません。最低スペックは4vCPU以上です。

EC2はIaaSですので、InnoRulesが依存するDBMS、Javaなどは事前にインストールされている必要があります。
コンテナ環境の場合、Javaを含むコンテナイメージを提供します。

ルール実行ログを出力します。Log4Jという3rd-partyライブラリを利用してログを出力しており、ログ出力レベルや出力先を変更することもできます。

ルール実行ログとして出力する項目は、実行ルールID、処理時間、成功有無、ログレベル、（エラー時）エラー詳細情報などです。既存ログ監視ツールはキーワード（例：Error、Exception）を利用して、ルールエンジンを監視できます。

InnoRules製品は作成したルールをRule Repository（DB）に保存します。

InnoRulesではプログラムソースを生成しないため、GibhubやSVNなどに資産管理することは出来ません。

InnoRulesはリリース日をルールバージョンとして付与することが出来ます。また、ルール実行時必ず、ルール実行基準日をパラメータに設定することで複数バージョンを同時に稼働させることも出来ます。

Rule Repository（DB）に保存されたルールデータをDBMS機能でExport/Importすることでデプロイ可能です。プログラムソースを生成しないため、ビルドは不要です。