FAQ

イノルールズ社の「教育・研修プログラム」には、有償の「①InnoRules R＆D教育サービス」と無償の「②BRMSハンズオン教育サービス」の2コースが用意されています。
「①InnoRules R＆D教育サービス」は、製品トレーニングと、貴社が調査研究を目的とする実行環境のご提供の他、貴社ご担当者様がスムーズにルール登録を行えるように育成するコンサルティングサービスとなっており、約3か月間かけて行います。
「②BRMSハンズオン教育サービス」 は、1～2か月間を目途に完全自習形式で完了できるコースであり、最新の製品機能と使い方の理解を進めることができます。教育サービスの他には技術支援サービスおよびルールInfra提供サービスがご利用できます。

■InnoRulesにて作成したルールは、汎用的なWebサービスプロトコル（ SOAP／REST）を利用して、簡単に呼
び出すことができます。
■呼出元アプリケーションの実装言語の最適化した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利用)

メジャーバージョンがリリースされる場合の旧バージョンへの対応は以下の通りです；
※現バージョンはV7.2で、メジャーバージョンはV7です。次のメジャーバージョンであるV8がリリースされた場合、EOL、EOSは次の通りになります。
EOL(End of Life) : 新規バージョンリリース後の6ヶ月後に販売活動終了
EOS(End of Support) : EOL終了後の5年間、標準保守サービスを提供
アナウンス：6ヶ月以前に代理店/顧客に通知します。

はい。基本的にはその製品のサポートは、サポート期間を超えた場合は行われません。
製品のサービス提供期間内に、製品のアップグレードをお願いしております。
ただし、サポート期間を過ぎた製品をご利用し続ける必要がある場合、個別にご相談させて頂きます。

InnoRules製品のバージョンアップにはマイナーバージョンアップ（v7.2 –>v7.3 ）とメジャーバージョンアップ（v7.x –> v8.x) があります。
■マイナーバージョンアップ
マイナーバージョンアップはバグ修正や簡単な機能追加、改善など製品仕様の変更が伴わないバージョンアップです。InnoRules側がお客様にパッチファイルと手順書を無償で提供するので、お客様がパッチ要否を判断してパッチを適用します。
■メジャーバージョンアップ
ルールリポジトリやルールAPI仕様変更など、製品仕様に変更が伴う場合もあります。もし、製品仕様の変更があり、ルールデータの移行が必要な場合、InnoRules側で移行ツールを無償で提供します。弊社が移行作業を実施する場合は有償サービスになります。

マイナーバージョンアップは１～２年に１回程
メジャーバージョンアップは５～７年に１回程
パッチは通常・緊急ふくめて適時発行いたします。

製品の脆弱性に関連する情報は弊社HPや保守サービスを通じて通知しています。

保守はお客様の一次窓口は販売代理店となります。ベンダーは代理店をサポートする立場となります。（以下同様）
■InnoRules社
ベンダーのサポート内容を以下に示します；
サポート体制は平日9時～17時稼働します。サポート受付はメールですので、サポート稼働時間外でも受付可能です。緊急性がある障害対応などが発生した場合、緊急電話連絡先を設けることも可能です。

製品にリモートアクセス機能は内包されていないので、御社NWにアクセス可能な手段を提供して頂き、SSHクライアントなどで実機にアクセスする形になります。

MySQL、PostgreSQL両方可能です。

無料のハンズオン(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サービス(SOAP/REST)連携機能を提供しています。また、I/F開発を支援するためのアシスタント機能もあります。それらの機能を使って各種言語(COBOL、C、Java等)で開発されたアプリケーションやパッケージシステム(SAP、CRM、BPM、Excel等)との接続実績が多数あります。

doubleです。

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

■技術的な面
InnoRulesで作成したルールはWebサービスで呼び出すことができるので、Webサービス呼び出し機能があるBPMからInnoRules呼出が可能です
■実績面
ある金融会社の事例です。
CamundaからInnoRulesをRESTで呼び出した実績があります。

InnoProductは商品データを商品リポジトリ（RDB）に格納しており、業務アプリケーションからもアクセス可能ですが、業務アプリケーションが直接参照することを推奨していません。
推奨しない理由は、
①業務アプリケーションが商品リポジトリから商品データを取得するためには、商品リポジトリのテーブル定義を理解する必要があります。ルールを利用する場合、PFキャッシュ用ユーザ定義関数が使えるので簡単に商品情報が取得できるので、業務アプリケーションが直接商品リポジトリにアクセスするよりルールを経由して商品データを取得した方が生産性が良いです。
②業務アプリケーションから商品リポジトリへ直接アクセスする場合、PFキャッシュが使えないため、ルール利用より相対的に性能が劣ります。
③商品リポジトリに性能問題が発生した時に、利用元が複数であれば、原因特定が困難になります。
④商品リポジトリの仕様変更が発生した場合、影響分析範囲や修正範囲が大きくなります。
⑤業務アプリケーションが商品リポジトリのデータを直接更新する恐れがあります。

実行のタイミングは呼び出し元のアプリケーションに依存します。
（時間の概念は製品にありません）
呼び出したときに、実行対象となるルールの制御はバージョン機能で実現できます。
（例）：ルールAのバージョンが2022/3/1と2022/4/1の2つある場合
アプリケーションがルール呼出時のパラメータに実行基準日付を指定します。
実行基準日付より前で直近のバージョンのルールが実行されます。
この場合、実行基準日付が2022/3/10であれば、ルールA（Ver2022/3/1)が実行対象となります。

アクションはルール呼び出し元へ結果を返却するのみです。
DB書き込みやメール送信などのアクションは呼び出し元が行います。

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

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

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

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

InnoRulesのルールエンジンはJavaルールエンジンですので、Javaが稼働できるサーバ環境であれば、ルールエンジンを稼働させることが可能です。
■オンプレ/Openシステムで利用する方法
①同じJVM上にアプリとルールエンジンを稼働させる場合
Rule APIを利用する方法ではアプリケーション言語がJavaの場合は、最大の性能を発揮できます。
②アプリとルールエンジンがリモート環境で稼働させる場合
Webサービスを利用する方法では、SOAPかRESTを利用してルールを呼び出すことができます。
■クラウドで利用する方法
①クラウドにルールサーバー環境を構築して稼働させる場合
サーバ上にJavaとルールリポジトリを構築、InnoRules製品をインストールしてルールエンジンを稼働させる方法です。アーキテクチャ設計・サーバ構築・管理・運用の検討が必要です。
②サーバーレス環境で稼働させる場合
AWS Lambdaのようにサーバーレズ環境のJava Runtimeを利用してルールエンジンを稼働させる方法があります。冗長化、スケーリングをクラウドが担当するので、サーバ構築・管理・運用の時間とコストが節約できます。（※ルール実行機能のみサーバーレス利用可能。ルール作成機能はサーバが必要）

Rule Builder v7.xの稼働条件を記します；
・OS　　MS Windows 7 以上
　※インストール時、管理者権限が必要。実行時は、標準ユーザでも OK
・解像度　1600×900以上
・HW　
　　CPU：2.4GHz 2Core以上
　　メモリ：２GB以上
　　HDD：100MB以上

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を利用して、ルールを呼び出すこともできます。
①、②の内、性能は①が若干良いですが、①の場合MF上コンパイル作業が必要であること（費用面）、COBOLにRule API依存コードを記述する必要があること（密結合）もあり、汎用プロトコルを利用できる②をお勧めします。
性能については、性能要件に合う十分な性能を満たすため、オンライン処理の場合はルールサーバのスケーリングを、バッチ処理の場合は並列処理で対応することが可能です。

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

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

EC2はIaaSですので、InnoRulesが依存するDBMS、Javaなどは事前にインストールされている必要があります。

仮想環境でも可能です。必要スペックは稼働環境のFAQをご参照ください。

ルール実行ログを出力します。Log4Jという3rd-partyライブラリを利用してログを出力しており、ログ出力レベルや出力先を変更することもできます。
ルール実行ログとして出力する項目は、実行ルールID、処理時間、成功有無、ログレベル、（エラー時）エラー詳細情報などです。既存ログ監視ツールはキーワード（例：Error、Exception）を利用して、ルールエンジンを監視できます。

InnoRules製品は作成したルールをRule Repository（DB）に保存します。InnoRulesではプログラムソースを生成しないため、GibhubやSVNなどに資産管理することは出来ません。

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

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