Corda Enterprise4.6 リリース
--
____________________________________________________
＜お知らせ＞
SBI R3 Japanブログは、MediumからSBI R3 Japanのポータルサイトに引っ越ししました。引っ越し先で、mediumの過去記事も閲覧可能です。今までとは異なる新しいコンテンツも発信してまいりますので、お気に入り登録をぜひお願いします！
____________________________________________________
Corda Enterpriseの新しいバージョンである4.6がリリースされました。
リリースノートの翻訳文を掲載いたします。
なお、皆様にいち早くお知らせするために抄訳版を掲載しています。全文訳につきましても、追って公開いたします。原文はこちらよりご確認ください。
Corda Enterprise 4.6 リリース概要
このリリースには、数多くの新機能や、機能上及び運用上の大きな機能改善、そして多様な既知の問題に対する修正が含まれています。
フロー管理の機能と改善
Corda Enterprise 4.6 によって、フロー管理に関する以下のような機能追加/改善が実現しました。
RPCやノードシェルを介してFlowデータを検索する機能が追加されました。
これにより、ノードオペレータは、a)期待通りに完了しなかった1つまたは複数のFlowを特定し、b)1つまたは複数のFlowに関連するステータス情報を取得する機能が提供されたことで、ノードオペレータがノード上で実行中のFlowを管理するのに役立ちます。
RPC とシェルを介したFlowの一時停止と再試行が可能になりました。
このリリースでは、ノードオペレータがFlow をcheckpointにおいて「一時停止」状態にし、問題のあるフローを効果的に「再起動しない」とマークすることができます。これにより、正しく動作しない事が想定されるFlowがノードの再起動時に自動的に再試行されることを防ぐことができます。この機能の為に、一連の新しいRPC呼び出しとノードシェルコマンドが導入されました。ノードオペレータは、一時停止しているすべてのフローを再試行することも、何らかの問題でFlowHospitalへ移行し、一時停止していたFlowを再試行することもできます。
Flowの重複開始を防ぐためにFlowごとに一意のIDを設定する機能が追加されました。
これはRPCクライアントを使用して行うことができ、フローを開始する際に一意の識別子を渡すことでフローを開始する追加の方法です。これにより、以下のことが可能になります。
- CordaノードへのRPC接続が切断された場合などに、Flowが正しく開始されたことを確認できます。
- IDが重複したFlowの開始を防止する — 同じ識別子でFlowを2回開始しようとしても、1回だけ実行します。
- 実行中のFlowの進行状況トラッカーを再取得できます。
- 完了したFlowの結果を再取得できます。
以下の動画で、RPC を介したフロークエリ、フローの一時停止、フローの再試行の概要を説明しています。
以下の動画で、RPC を使用したフローの問い合わせ、フローの一時停止、フローの再試行について解説しています。
以下の動画で、ユニークなIDを介してフローの重複開始を防止する機能の概要を説明しています。
運用に関する機能の改善
- Corda オープンソースと Corda Enterprise でのデータベーススキーマ管理の方法を合理化しました。これには、データベース管理ツールの改善が含まれています。
- Corda Enterprise FirewallとすべてのCorda Enterpriseセットアップツールを含んだDockerイメージをリリースしました。
- Flow state machineの安定性を増す多くの改善が含んでいます。
- Corda Firewallを実行していなくても、ノードのTLSキーをHSMに保存できるようになりました。node.conf の enterpriseConfiguration 内に新しいオプションの tlsCryptoServiceConfig セクションが導入されました。
- ノードメンテナンスモードを導入しました。これにより、ノードのメンテナンススケジュールを実現できるようになりました。この機能はNode.confのEnterpriseConfigurationセクションに新しく追加されたmaintenanceModeフィールドを設定することで実現されます。
- メッセージ ID のクリーンアップをあまり積極的に行わない機能が追加されました。過去に処理済みであるメッセージ識別子のクリーンアップが以前より慎重かつ安全に実行されます。
開発に関する機能改善
私たちは、開発者にとって使いやすいプラットフォームとしての Corda の地位を維持するために、デベロッパーエクスペリエンスを全体的に改善することに焦点を当てています。このリリースでは、開発者がより柔軟にアプリケーションを構築するのに役立つように、いくつかの改善が行われています。
- 復帰不能なチェックポイントが自動検出されるようになりました。開発中、フローはチェックポイントに到達するたびに自動的にシリアル化され、その後デシリアライズされるようになりました。これにより、デシリアライズできないチェックポイントを作成するフローコードを自動的に検出できるようになりました。
- CorDappのチェックポイントにプラグイン可能なカスタムシリアライザを登録します。Checkpointに到達したFlowをシリアライズする際に、カスタムシリアライザを使用できるようになりました。ほとんどのクラスではカスタムシリアライザは必要ありません。この機能は、シリアライズ中に例外を投げるクラスに対応するために存在します。新しい CheckpointCustomSerializer インターフェイスを実装して、カスタム・チェックポイント・シリアライザを作成します。
このリリースノートをよく読んで、このリリースで何が新しくなったのか、新しい機能や機能強化がどのように役立つのかを理解してください。
Corda Enterprise 4.6 は本番環境では Linux をサポートしていますが、Windows と macOS のサポートは開発とデモンストレーションのみを目的としています。詳細については、Corda Enterprise プラットフォームサポートマトリックスを参照してください。
Corda Enterprise 4.6 は Corda Enterprise 4.5 を拡張したもので、Corda (オープンソース) 4.x と 3.x、および Corda Enterprise 4.5, 4.4, 4.3, 4.2, 4.1, 4.0, 3.x と動作互換性があります。詳細については、Corda（オープンソース）リリースノートを参照してください。
これまでのリリースで後方互換性とAPI互換性が約束されていたように、Corda 4.6 でも同様の保証がされています。Corda 3.0 以上で有効な状態とアプリは、Corda 4.6 でも使用可能です。
プラットフォームのバージョン変更
Corda 4.6 のプラットフォームバージョンが 7 から 8 に更新されました。
プラットフォームのバージョンの詳細については、こちらのバージョン情報を参照してください。
重要なアップグレードと移行の注意点
Corda 4.6 で行ったデータベーススキーマの調和に関する運用上の改善は、以前のバージョンから Corda 4.6 と Corda Enterprise 4.6 にアップグレードする場合や、Corda オープンソースから Corda Enterprise にアップグレードする場合には、いくつかの手動の手順が必要になります。これらの手順の詳細については、以下のリンクをご覧ください。
アップグレードパスごとに必要な手順の簡単なチェックリストを以下に示します。
既存のノードを Corda 4.5 (またはそれ以前の 4.x バージョン) からバージョン 4.6 にアップグレードする
- ノード構成ファイルのデータベースセクションから、transactionIsolationLevel、initialiseSchema、initialiseAppSchema、およびrunMigrationのエントリをすべて削除します。
- run-migration-scripts モードでノードを実行して、不足しているコア・スキーマの変更を更新します。
- CorDapps に Liquibase リソースを追加します。Corda 4.6 では、カスタムスキーマを導入する CorDapps には、スキーマを前もって作成できる Liquibase マイグレーションスクリプトが必要です。リソースに移行スクリプトがない既存の CorDapps に対しては、データベース管理スクリプトで説明されているように、外部の移行用 .jar ファイルとして追加することができます。
- 既存のスキーマの変更ログを更新します。Corda .jar ファイルをアップグレードし、CorDapp に Liquibase スクリプトを追加した後、アプリからのカスタムスキーマはデータベースに存在しますが、Liquibase changelog テーブルの changelog エントリが欠落しています (Liquibase によって作成されているため)。このため、ノードを起動するときに問題が発生します。また、すでに存在するテーブルを再作成できないため、run-migration-scripts を実行するときにも問題が発生します。新しいサブコマンド sync-app-schemas を実行することで、CorDapps の既存のマップされたスキーマの changelog エントリが作成されます:（ java -jar corda.jar sync-app-schemas）.
重要 sync-app-schemas サブコマンドを実行する前に、新しい CorDapp やスキーマエンティティを追加したバージョンをインストールしないでください。CorDappsで見つかったマップされたスキーマは、一致するデータベースエンティティを作成しようとせずに変更ログに追加されます。
重要 スキーマがマップされた CorDapp がインストールされている間にノードを Corda 4.6 にアップグレードする場合、ノードを再起動したり、アプリのスキーマの更新を実行したりする前に、スキーマを同期させなければなりません。したがって、ノードをアップグレードしている間、またはアップグレード後であってもアプリスキーマを同期する前に、新しいスキーマまたは変更されたスキーマを持つ CorDapp をインストールしたり、更新したりしてはいけません。
Corda 3.x または Corda Enterprise 3.x からのアップグレード
Corda 4.6 では、4.0 より古いバージョンの Corda から移行する際に、データベースの変更履歴を後付けするサポートが削除されました。そのため、Corda 4.6 に移行する前に、前のバージョンの 4.x に移行する必要があります — 例えば、3.3 から 4.5 に移行した後、4.5 から 4.6 に移行する場合などです。
初期ノード登録コマンドを実行する際の注意点
Corda Enterprise 4.6では、データベースの移行はデフォルトで初期ノード登録時に実行されます。
これを防ぐには、 — initial-registration コマンドと一緒に — skip-schema-creation フラグを使用してください。
初期登録コマンドについては、「ノードのコマンドラインオプション」と「互換ゾーンへの参加」で説明しています。
・・・・・・・・・・・・・・・・・・・・・・・・・・
Facebook： https://www.facebook.com/R3DLTJapan
Twitter： https://twitter.com/R3Sbi
HP： https://sbir3japan.co.jp/product.html
お問い合わせ：info-srj@sbir3japan.co.jp
