最初に行ったのは、ポート80が無効になっているブラウザと動作しているバージョンのフラッシュを「フリーズ」することでした。大多数がそうだったと思います。
2番目のステップは、ターゲットソリューションとして使用することは非常に可能です。ポート80を無効にしてMaxthon 5ブラウザーを使用し、「フラッシュ解除」の必要性を忘れます。このソリューションは、それ自体は更新されないブラウザバージョン（最終バージョン）の特殊性と、更新されない27番目のバージョンのフラッシュプレーヤーを使用するために選択されました。
3番目（そして最も高価）は、ソフトウェアをフラッシュに依存しないバージョンに更新することです。このタスクには、SASベンダー、Globyte LLCの実装チーム、およびIT銀行チームの努力が必要でした。ベンダー側からは、フラッシュ依存モジュールをHTML5に作り直し、システムの既存のインスタンスを更新するためのツールを提供する必要がありました。実装チームの側から-実装の詳細とそのカスタマイズを考慮して、更新戦略を選択し、計画を立てます。 ITチームの側で、ビジネス顧客とのアプローチを調整し、作業が実稼働環境で実行されるようにします。
SAS製品の場合、システムをアップグレードするための2つのオプションがあります。 1つ目は、インプレース更新です。基本的に、これは既存の実稼働環境にインストールされるSASプラットフォーム用の大規模な製品更新パッチです。もちろん、最初のインストールは非産業用スタンドで実行されます。ここでは、カスタマイズがあった場合、製品のカスタマイズされた部分のコードをマージし、回帰テストを実行する必要がある場合があります。そして次のステップは、産業革命前および産業用スタンドを更新することだけです。
ただし、インプレース更新が常に可能であるとは限りません。たとえば、製品が進化し、新しいバージョンが異なるアーキテクチャと異なる技術スタックで構築されている場合などです。この場合、新しいソフトウェアバージョンへの本格的な移行が必要です。これは、SASソフトウェアを更新するための2番目のオプションです。
そして、SASAMLソリューションがそれ自体を見つけたのはこの状況でした。近年の私たちの成果は、財務監視部門向けのAMLシステムを構築するための大規模プロジェクトの第1段階の立ち上げと実施です。このプロジェクトの特徴は、これが銀行で最初のプロジェクトであり、その枠組みの中で、新しいオンラインデータ処理プラットフォームであるODPPの機能が十分に活用されたことです。最初のフェーズでは、必須の監視およびレポート要件が実装されました。 2019年末から、プロジェクトの第2フェーズが開始されました。これには、疑わしいトランザクションの特定とオンライン制御の分野での機能の開発が含まれます。インダストリアルモードでは、SAS AML6.3バージョンはSAS9.4 M3プラットフォームで動作し、新しいソリューションバージョンであるSAS AML8.2は更新されたSASViya3.5プラットフォームで提供されます。新しいプラットフォームは新しいマイクロサービスアーキテクチャ上に構築されており、新しい製品が含まれています。したがって、新しいバージョンに移行するときは、機能の一部を適応させ、他の部分を再実装する必要があります。
私たちが直面した目標は、脱肉作業を完了し、プロジェクトの第2フェーズの方針に遅れずについていくことでした。 SAS AMLシステムの場合、2段階の順次移行が選択されました。
最初の段階では、フラッシュ依存モジュールを移行する必要があります。これにより、深刻な問題が解消され、ブラウザーのフリーズが回避されます。フラッシュ解除が必要なメインモジュールは、分析レポートと管理レポートを作成および視覚化するためのツールであるSAS VisualAnalyticsです。新しい機器の割り当てとSASViya3.5プラットフォームへの新しいバージョンのSASVA 8.5の展開に加えて、ソリューションの統合やETLプロセスのセットアップなど、いくつかの必須タスクを解決する必要があります。透明性とユーザーエクスペリエンスを保証するタスクの数。たとえば、データの再入力を回避するためのエンドツーエンド認証（シングルサインオン）の設定。次の段階は、SAS AML 8.2ソリューションの新しいバージョンへの完全な移行です。システムの全機能の転送、統合のセットアップ、新しいシステムをパイロット運用に投入し、移行期間中の2つのシステムの存在をサポートします。
同僚、あなたの経験を共有してください：あなたはどのようにDe-Flashタスクに対処しましたか？
記事の著者- @ DSSD