最新のIRM-IP17へのSiebelアップグレード+

冗談はさておき-永遠について話しましょう。 この投稿では、喜びのスプレーや存在のしやすさのヒントは見つかりません。 なぜなら、それは戦って捜索した人たちのためであり、Siebelのアップグレードのすべての新しいラウンドに合格するからです。 オラクルは2013年以来、CRMシステムを根本的に近代化するキャンペーンを実施しています。 これまでに、7つの（IP13からIP19までの）イノベーションパックをすでに経験しています。 2013年まで、リリースは2〜3年ごとにリリースされ、過去5〜6年のSiebelアップデートははるかに頻繁に公開され、明確なスケジュールを守っていました。マイナーリリース（パッチセット）は毎月リリースされました。システムのグローバルな処理または「再導入」も可能です。 Siebelのアップグレードを簡素化するために、ベンダーはIRM（Incremental Repository Merge）を開発しました。これは、イノベーションパッケージを含む新しいバージョンのインストールプロセスを容易にする機能です。 それについて説明します。

IRMの原則

Innovation Packを使用してシステムを新しいバージョンに更新するには、システムリポジトリを更新する必要があります。 これを行うには、新しいバージョンのリポジトリとマージします。

リポジトリはシステムメタデータ、つまり その機能であるすべてのスキーム。 プロジェクト中に、顧客コンサルタント開発者（Siebelコンシューマー）がリポジトリに何千もの変更を加えます。 ただし、これらの変更はOracleからのリリースの配信には存在せず、ベンダー自身がシステムを変更して新しいメタデータを追加し、特定のオブジェクトスキームを完全に作り直すことができます。



明らかに、システムのコンシューマーによって行われた変更をOracleの新しい開発とシームレスに結合できるメカニズムが必要です。 このために、IRMが作成されました。



Siebelアップグレード中に解決されたタスク

1. 統合のためのリポジトリと環境の準備。
   
   
2. 更新環境（DEV）（IRM）での直接統合。
   
   
3. 競合の分析と解決。
   
   
4. 更新環境に変更を適用します。
   
   
5. 回帰テスト。
   
   
6. 更新中に発生したすべての欠陥の修正。
   
   
7. アップグレード環境から実稼働前、さらに実稼働への移行。
   
   

IP17 +に切り替えるメリットは何ですか

1. 新しいエンジン：OpenUI-インターフェースをより深く設定する機能により、システムの使いやすさが向上します。
   
   
2. システム内のユーザーの行動の機能分析（使用パターン追跡）は、独自のUXを作成します。
   
   
3. ブラウザー間のサポート：IEはもはや制限ではありません-Edge、Firefox、Chrome、Safariで作業できるようになりました。
   
   
4. WebTools（Composer）ツールを使用すると、サーバーの再起動を必要とせずに、ブラウザからシステムのインターフェイスとビジネスロジックを変更できます。 ダウンタイムなし。 開発プロトタイピングがより高速になりました。
   
   
5. CI / CDテクノロジー、パッチ転送の自動化、並行開発、自動テスト。
   
   
6. REST統合テクノロジーのサポート。これは、クライアントポータルと統合する場合に適しています。
   
   
7. 業界の革新：人気のあるJSライブラリ上に美しい分析ダッシュボードを構築することから、ビッグデータと機械学習テクノロジーまで。
   
   

アップグレードを成功させる鍵

IRMは、元のリポジトリ、顧客バージョン、および新しいバージョンに存在するオブジェクトとプロパティの不一致のセットを定義します。 この機能により、開発者の決定に基づいて、オブジェクトを結合する方法を選択し、最後の段階で、更新されたリポジトリを更新環境から本稼働環境に移行する効果的なプロセスを開始できます。



マージ中に競合が発生します。つまり、現在のリポジトリのオブジェクトのプロパティと、新しいバージョンのリポジトリの同じオブジェクトのプロパティの違いが発生します。



重大ではない競合とは、顧客の影響を受けていないオブジェクトの不一致です。 元のリポジトリと新しいリポジトリの不一致。 このような競合の99％は、新しいリポジトリを使用して解決されます。



重大な競合は、クライアントリポジトリと新しいリポジトリのオブジェクトの違いです。



プロジェクトの最初からOracleの方法論に従うと、その後のアップグレードに必要なコストは最小限になります。 ただし、残念ながら、特定の顧客の要件を満たす場合、Oracleのベストプラクティスが犠牲になることが非常に多くあります。 たとえば、システムテーブルはデータベースを介して直接変更されることがありますが、これはSiebelリポジトリで修正されていません。 または、ユーザーキー（UK）、ディメンション、および標準テーブルの標準列のタイプを変更します。これは、実行しないことを強くお勧めします。 これにより、本稼働への移行中にテーブルを自動的に再構築することができなくなり、テーブルとデータを使用した多くの手動操作が必要になります。 さらに、標準のキーと列を変更すると、Siebelの新しいバージョン用に開発された新しいプロセスのパフォーマンスに影響する場合があります。

したがって、システムは、広範な実装経験を持つ認定された専門家の監督の下で実装されることが重要です。



ただし、アップグレードプロジェクトで最も重要なことは、プロセスを適切に計画することです。その間、いくつかの問題を一度に解決する必要があります。



ソリューション基盤

• インフラストラクチャを構成するのは誰ですか：
  
  
  • サーバーを展開する
  • OSを設定する
  • RBSを構成する
• 更新環境の説明。 IRMはどこで行いますか？
• テスト環境の説明。 どのようにテストしますか（外部システムと統合を含む）？
• デプロイメント環境の説明。 現在の製品を更新するか、並行運用環境をセットアップしますか？

詳細なプロジェクト計画（顧客と請負業者間の責任の配分を考慮に入れて）

• 生産者に新しい機能を導入する作業を「凍結」する必要があることに注意してください。
• 含む アップグレードプロジェクトの開始後に本稼働に入ったすべての機能パッケージを再インストールする必要があることを考慮する必要があります。

テスト計画

• 回帰テストスクリプトを作成する必要があります。
• 責任者を特定し、CRMと外部システムの両方のテスターのチームを決定します。

実施計画

• 生産性の向上にアップグレードを導入する作業のチェックリストを作成します。
• アップグレード中に事故が発生した場合に備えて、ロールバック計画を作成します（yes、yes！;）。

それとは別に、システムの完全な監査（またはベンダーに注文すること）を実施して、開発者がどの方法論の違反や実装の技術的エラーを犯したかを調べることは理にかなっています。 監査はオラクル認定の専門家によって実施され、結果は「独自の」Oracle Siebelプロトコルの形式で記録されます。

1. 構成レポート（ビジネスロジック構成のエラーまたは違反）
   
   
2. 統合レポート（統合オブジェクトのエラーまたは違反）
   
   
3. スクリプトレポート（プログラマブルモジュールのエラーまたは違反）
   
   
4. プロセスのエラー（ワークフローおよび自動機能のエラー）
   
   

実際には、変更された機能でエラーが発生する可能性があります。 組み合わせたソリューションの回帰テストの段階では、組み合わせの結果としてどのエラーが発生し、どのエラーが元々発生したかを正確に理解する必要があります。



Siebelをアップグレードする際の最も重要な問題

最新のIRM、または最新のSiebel（IP19）へのアップグレード方法

過去2年間で、Siebelシステムで大きな変更が行われ、システムの更新方法も変更されました。



主な変更は、2017年のIP17のリリースとその後の更新に関連しています。

• システムデータモデルが作り直され、ベンダーはサーバーの起動時に使用されるSRFコンパイルファイルを拒否しました。 Runtime Repositoryが表示されます。これにより、システム構成を再起動せずに変更できます。
  
  
• Siebel Web ServerはスタンドアロンのSiebelコンポーネントになりました。今後は、サードパーティのIISやApacheなどのコンポーネントは不要になりました。 Application Interface（AI）と呼ばれるSiebel WebServerは、Tomcatコンテナに基づいて実行されます。 AIへのすべての接続はHTTPS経由でのみ行われます。 すべてのトラフィックはデフォルトで暗号化されます。 AIは、着信要求と発信要求の両方を完全にRESTでサポートします（RESTテクノロジーは、システムの改善点のインストールやリポジトリのアップグレードのプロセスに大きな柔軟性を与えます）。
  
  
• Gatewayコンポーネントがアップグレードされました（現在はDynamic Gatewayと呼ばれています）。 特に注目すべきは、再設計された内部コンポーネント間バランシングです。 ゲートウェイ（Gateway Elastic Load Balancer）がそれを担当するようになりました。これにより、負荷分散システムがより柔軟になります。以前は、この機能はアプリケーションサーバーによって実行されていました。
  
  
• システムは、Oracle 12データベースを公式にサポートしています（Oracle 11gデータベースのサポートは完了しています）。
  
  

2018年、OracleはSiebel CRMのリリースポリシーを変更しました

• 将来のすべての革新と修正は、更新、つまり配布キットから現在のバージョン（IP17以降）にインストールされるパッチセットとして提供されます。 これには、システム開発戦略でベンダーが以前に示したイノベーションが含まれます。
  
  
• パッチセットの名前はより明確になります。 バージョンは毎月リリースされます。たとえば、番号18.4は「2018年4月」を意味します。
  
  
• 新しい配信モデルは、バージョン18.4から始まります。 古いモデルの最新バージョンは17.6でした。 17.6から18.4に移行するには、配布キットをインストールするだけです（IRMアップグレードとしてではなく、パッチとして）。 その後の月次更新には、特別なユーティリティを使用して変更の小さなパッケージをダウンロードする必要がある機能が含まれる場合があります。 さらに、すべての更新は累積されます。
  
  
• モデルの変更により、IP17に切り替えたクライアントは、システムのバージョンのパッチが不足するという問題に直面することはなくなります。 同時に、システムのアップグレードプロセスが大幅に簡素化され、サポートのコストが削減され、革新的な機能の導入が加速されます。
  
  
• たとえば、Siebelの以前のバージョン（最大17）からバージョン19にアップグレードするには、バージョン17への標準アップグレードを実装してから、新しい更新モデルを使用する必要があります。
  
  

IP17 +にアップグレードする方法の変更

インフラストラクチャを設計し、サイジングを行う場合、新しいサーバーインフラストラクチャIP17を考慮する必要があります。 鉄の要件が増加します、なぜなら ランタイムリポジトリにはより多くのリソースが必要です。 新しいアプリケーションインターフェイスとゲートウェイコンポーネントのフォールトトレラントバランシングでは、2ではなく3つのコンポーネントを推奨します。サーバー構成とサーバープロファイルを確認して、新しいIP17アーキテクチャに移行する必要があります。



また、HTMLテンプレート、JS、CSSなどのすべてのWebアーティファクトを新しいApplication Interface Webサーバーに転送する必要があります。 ところで、すべてのWebアーティファクトは最終的にシステムリポジトリに移動します。



次の手順では、オペレーティングシステムとデータベースをサポートされているバージョンに更新し（OracleサポートのSiebelソフトウェア認定タブを確認する必要があります）、正しいHTTPS証明書を発行します。



最後に、最後にIRMを開始する必要があります。さらにバージョンを更新するには、パッチをインストールするだけです。



IP17 +へのアップグレードと並行して、現在のバージョンのシステムで新しい機能を開発している場合は、付属のドキュメントを再テストして更新する必要があります。 また、開発者と管理者は、Workspaceテクノロジ、移行ツール、および新しいSiebelインフラストラクチャ管理管理コンソールを使用するように訓練されています。



次の表から、現在のバージョンに応じてアップグレードへのアプローチを決定できます。





*** SEAおよびSIA Siebel CRMリリースの詳細については、My Oracle Supportの記事1514115.1を参照してください。

道徳

明らかに、そのようなプロジェクトには、落とし穴を予測して回避し、顧客が圧倒されないようなアップグレードプロセスを適切に計画することができる経験豊富なコンサルタントの関与が必要です。 つまり システムのダウンタイムの長期化、データ損失、アップグレード後のビジネスプロセスの重大なエラーのリスクを最小限に抑え、さらには排除します。 たとえば、テーブルキーの選択を間違えると、システム内のプロセスの大規模な処理が必要になる可能性があります。その後、単純な更新によって数か月間プロジェクトに変わるリスクがあります。



マキシムチュガンキン、システムアーキテクチャグループ、Jet Infosystemsの責任者