Corda Enterprise 4.6 – SBI R3 Japan

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 でも使用可能です。

新機能と機能強化

マルチRPCクライアントを介して新しいリモートRPCインターフェースにアクセスする機能

Corda Enterprise 4.6では、マルチ RPC クライアントと呼ばれる新しいRPCクライアントが追加されました。

Nodeペレータは、マルチ RPC クライアントを使用して、以下のカスタム、リモート RPC インターフェイスのいずれかを介して Corda Enterprise Nodeと対話できるようになりました。

net.corda.client.rpc.proxy.AuditDataRPCOps: RPCアクティビティのログを監査できるようにします。
net.corda.client.rpc.proxy.FlowRPCOps: 以前にFlow Hospitalに入ったFlowを再試行できるようにします。
net.corda.client.rpc.proxy.NodeFlowStatusRpcOps: 外部アプリケーションがFlow Hospitalによって現在監視されているFlowのステータスを照会して表示することを可能にします。
net.corda.client.rpc.proxy.NodeHealthCheckRpcOps: Corda Enterprise Nodeの状態に関するレポートを取得できるようにします。
net.corda.client.rpc.proxy.notary.NotaryQueryRpcOps: 特定のstate参照に対して消費済監査を実行できるようにします。

これらのインターフェイスはすべて client:extensions-rpc モジュールにあります。Corda Enterprise のお客様は、これらのインターフェイスを拡張して、Corda Enterprise Nodeの管理に役立つユーザー定義のカスタム機能を追加することができます。

COMPLETED、FAILED、およびKILLEDFlowは、クライアントが提供する一意のIDを使用してstartFlowWithClientId APIまたはstartFlowDynamicWithClientId APIによって起動された場合にのみ、クエリを行うことができます。

詳細については、「Nodeとの対話」ドキュメントのセクションを参照するか、API ドキュメントの「マルチRPCクライアント」を参照してください。

RPCおよびNodeシェルを介してFlowデータをクエリする機能

Corda Enterprise 4.6では、Flowチェックポイントデータを照会する機能が導入されました。これにより、Nodeペレーターは、Node上で現在実行中のFlowのセットを管理することができ、a)期待通りに完了しなかった1つまたは複数のFlowを特定し、b)1つまたは複数のFlowに関連するステータス情報を取得することができます。

Node演算子は、以下のいずれかのメソッドを使用してFlowの状態を問い合わせることができます。

新しい net.corda.client.rpc.proxy.NodeFlowStatusRpcOps インターフェイスを使用して、RPC を介してNodeと対話したり、Flowステータスを問い合わせたりすることができます。
新しいflowstatusコマンドを使用して、Node・シェルを介して手動でNodeに問い合わせを行うことができます。

どちらの方法を使用しても、Nodeを問い合わせることで、Nodeオペレーターは以下のことが可能になります。

期待通りに完了していないFlow（サスペンドFlow）のリストをすべて返します。
以下のような特定の検索条件を満たすすべての中断されたFlowを返します。

現在の Corda ランタイム環境と互換性が有る、または無いFlow
特定のCorDappに関連しているFlow
特定のFlowクラスが含まれている、またはいないFlow
特定の時間枠内で実行されたFlow
特定の状態にあるFlow
特定の進行ステップを超えて進まなかったFlow
特定の時間の間、チェックポイントにスタックしているFlow

1つまたは複数の中断されたFlowのステータス情報を取得します。

詳細は「Flowデータのクエリ」ドキュメントを参照してください。

Flowの一時停止と再開を行う機能

NodeペレータがFlowチェックポイントを「一時停止」状態に設定できるように、新しいRPC呼び出しとNodeシェルコマンドのセットが追加され、問題のあるFlowを「再起動しない」とマークし、Nodeの再起動時に自動的に再試行されるのを防ぐことができるようになりました。

一時停止したチェックポイントは、Nodeの再起動時にメモリにロードされません。これは、Nodeのオペレータがメモリ使用量を管理するのに役立ちます。同時にロードされるチェックポイントが多すぎると、Nodeがクラッシュして再起動ができなくなる可能性があります。

Nodeペレータは、現在一時停止しているすべてのFlowを再試行することも、以前、Flow Hospitalにはいって一時停止していたすべてのFlowを再試行することもできます。Flow HospitalにはいったFlowはRPC経由で再試行することができるため、再試行のトリガーとしてNodeを再起動する必要がありません。

詳細については、「Flowの一時停止と再開」を参照してください。

Flow重複開始防止機能と、開始済Flowの状態を取得する機能

CordaのRPCクライアントでは、各Flowを一意のクライアントIDで起動できるようになりました。
この方法でFlowを開始することには、以下のような利点があります。

同じクライアントIDでFlowが複数回呼び出された場合、それらは重複しているとみなされます。最初の呼び出しの後に続くすべての呼び出しは、単に最初の呼び出しの結果を返します。
実行中のFlowは、クライアントIDを使用して再アタッチできます。これにより、そのFlowハンドルを再取得することができます。
完了したFlowの結果は、Flowが完了した後でも、クライアントIDを使用して確認することが
できます。

また、以下のようなことも可能になります。

既に開始したFlowに対して、確実な再接続ができます。
Flowの結果や例外を実行後いつでも再利用することができます。

詳細については、「クライアントが提供する一意のIDでFlowを開始する方法」を参照してください。

Databseスキーマ管理方法の統一

Corda Open Sourceと Corda Enterprise でDatabaseスキーマ管理を行う方法を統一しました。

Nodeの設定ファイル(node.conf)に記載する方法から起動オプションで指定する方法に変更しました。 (設定ミスを減らし、オプションの変更がより簡単になるようにするためです)。
Node起動の際に、Databaseスキーマを作成/アップグレードする機能を削除しました。代わりにスキーマ作成/移行用の起動オプションを導入し、Nodeのインストール/アップグレード作業の一部として実行するようにしました。
Corda と Corda Enterprise の間でDatabaseの設定方法、セットアップ方法、そして動作方法を
統一しました。
4.0以前のバージョンのCordaからの更新時の自動スキーマ移行を削除しました。
CorDapps用のLiquibaseスキーママイグレーション/記述スクリプトを導入することで、Corda Open SourceでカスタムCorDappスキーマをLiquibaseマイグレーションにパッケージ化できるようになりました。

スキーマの移行/作成が通常のNode実行モードから切り離され、別の起動オプションを使用する必要があります。4.6以前の設定ファイル(node.conf)にあったスキーマの移行に関連するすべてのオプションは使用不可になったため、Corda 4.6 で使用するとエラーが発生になります。

さらなる重要な変更点は以下の通りです。

CorDappsのためのスキーマ管理

Corda 4.6 は、Corda Enterprise と同様に Liquibase を介した CorDappsスキーマの移行をサポート
しています。

各 CorDapps は、必要なスキーマを作成/移行するために Liquibase スクリプトを使って移行リソースを提供する必要があります。
移行スクリプトを持たない古い Corda オープンソースの CorDapps は、Corda Enterprise の Enterprise migration ドキュメントで説明されているのと同じ方法で移行する必要があります。
NodeはHibernateを使って、H2をdevモードで使用してアプリスキーマを自動的に管理することができます。これを有効にするためには、起動オプションとして、--allow-hibernate-to-manage-app-schema を設定する必要があります。

スキーマの作成

Corda 4.6 では、Corda Nodeは通常の実行モードではスキーマを動作中に変更/作成できなくなりました。代わりに、run-migration-scripts という新しい起動オプションを使って、スキーマの設定や変更をあらかじめ適用する必要があります。この起動オプションはスキーマを作成/変更して終了します。

コア・スキーマとアプリ・スキーマへの分割

Corda Nodeは、Node自体が動作するために必要なコア・スキーマのセットを持っています。さらに、CorDappsは、カスタムStateをVaultに保存するために、追加のマップされたスキーマを定義することができます。
Corda 4.6までは、Node/スキーマの移行は両方の組み合わせを使用し、ハードコードされたリストとヒューリスティックを使用して、必要なスキーマの作成/移行をすべて実行して、どちらがどちらであるかを判断していました（例えば、コア・スキーマとアプリ・スキーマでは、CheckPointがデータベースに存在している間に実行できるかどうかの要件が異なるため）。
Corda 4.6の変更によって、run-migration-scripts起動オプションは、--core-schemasと--app-schemasの2つの新しいパラメータを取ります。これらのパラメータのうち少なくとも1つが存在していなければならず、それぞれの要求されたスキーマセットに対してマイグレーションスクリプトを実行します。

CheckPoint(CordaのFlowが他のノードとの間で未完了のFlowを保持している場合など、FlowCheckPointをノードが保持している状態)が存在している場合、コア・スキーマの移行はできません。アプリ・スキーマに関してはCheckPointが存在していても、--update-app-schema-with-checkpoints フラグを使用して強制的に移行させることが可能です。

テスト

自動化されたテスト（MockNetwork、NodeBasedTest、Node Driver テストのように）は、必要な
スキーマを自動的に設定することができます。

MockNetworkを使ったテストの場合、MockNode はAbstractNode のフィールドをオーバーライドして、その場でスキーマのマイグレーションを実行できるようにします（コマンドラインからは利用できません）。Liquibase を実行するかどうか、Hibernate を使ってアプリのスキーマを作成するかどうかを制御するために、余分なコンストラクタのパラメータを取ります。既存のテストとの互換性を保つために、どちらもデフォルトでは true になっています。
Node Driverを使ったテストの場合、インプロセスNodeはMockNode と同様のメカニズムを使用します。永続データベースを使用するアウトオブプロセスNodeは、起動前にデータベースをセットアップする必要があります（実際のNodeと同様）。そのため、この場合、DriverDSL はNodeを実行する前にスキーマ移行ステップを実行します。インメモリデータベースを使用するアウトオブプロセスNodeは特に厄介なケースで、Nodeが起動する前にセットアップできる永続データベースがないためです。したがって、Node自体はH2インメモリJDBC URLをチェックすることができ、それが検出された場合は必要なマイグレーションを実行します。
NodeBasedTestを使ったテストの場合は、NodeDriverと同じインプロセスNodeを使用します。

ブートストラップ

Network Bootstrapperは、ブートストラップ・プロセスの一部として、コア・スキーマの移行を実行します。

Cordformationには、以下のようにbuild.gradleのNodeセクションに追加できる追加パラメータがあります。

runSchemaMigration = true

これにより、コードフォームのセットアップの最後のステップとしてスキーマの完全移行が実行され、Nodeの実行準備が完了します。

設定ファイル（node.config）のフィールド変更

以下のフィールドは、設定ファイル(node.conf)のデータベース・セクションから削除されました。これらのフィールドが見つかるとNodeが起動時に例外をスローするため、設定ファイル(node.conf)から削除する必要があります。

transactionIsolationLevel: これはNodeでハードコードされるようになりました。
initialiseSchema: 上記のとおり、スキーマはNode起動時に初期化できなくなりました。
initialiseAppSchema: 上記のとおり、スキーマはNode起動時に初期化できなくなりました。
runMigration: これは非推奨です。スキーマの移行は、データベース管理ツールか新しい
run-migration-script サブコマンドでのみ実行できます。

さらに、devModeでスキーマ移行リソースなしでCorDappを実行できるようになりました - Corda Enterprise 4.6では、Cordaオープンソース4.6と同様に起動オプションとして--allow-hibernate-to-manage-app-schemasが利用可能になり、devModeで実行する際のアプリスキーマの存在のチェックが緩和されました。

スキーマ管理ドキュメントをご覧いただきまして、CorDapp のパッケージングプロセスにどのような調整が必要かをご確認いただければと思います。

V4.0 以前の Corda バージョンからのスキーマの移行

Corda 4.6 では、4.0 より古いバージョンの Corda から移行する際に、Databaseの変更履歴を後付けするサポートが削除されました。そのため、Corda 4.6 に移行する前に、前のバージョンの 4.x に移行する必要があります - 例えば、3.3 から 4.5 に移行した後、4.5 から 4.6 に移行する場合などです。

データベース管理ツールの改善

Corda から Corda Enterprise へのデータベース移行を容易にするために、データベース管理ツールを改良しました。

以下、変更点を説明します。

新しい sync-app-schemas コマンドが追加されました。このコマンドは、利用可能なすべてのCorDappsのマイグレーションの変更履歴を更新します。
dry-runコマンドには、--core-schemas（コアNodeスキーマの移行を適用するためのDB固有のDDLを出力）と--app-schemas（カスタムCorDappスキーマの移行を適用するためのDB固有のDDLを出力）という2つの新しいパラメータが追加されました。
execut-migration コマンドには、3つの新しいパラメータが追加されました。--core-schemas はNodeの Liquibase コアスキーママイグレーションを実行します。また--app-schemas はカスタム CorDapp スキーマの Liquibase マイグレーションを実行します。そして--db-admin-config <path/to/adminconfigfile> は、DB のための高いアクセス資格情報を要する設定ファイルのディスク上の場所を指定し、設定ファイルに記載されている資格情報を使用して、Nodeデータベースに接続し、変更を適用します。
難読化されたパスワードが許可されるようになりました。ツールが難読化されたフィールドの難読化を解除できるようにするために、必要に応じてパスフレーズとシードを設定するための以下のコマンドラインオプションが提供されています: --config-obfuscation-passphrase、--config-obfuscation-seed
ベースディレクトリが設定されていない場合は、現在の作業ディレクトリがデフォルトとなります。
dry-runを使用した場合の出力ファイルの場所：出力ファイルは、ベースディレクトリではなく、現在の作業ディレクトリに相対的に作成されるようになりました。

詳細については、「データベース管理ツール」を参照してください。

CorDapp チェックポイント用のカスタムプラグインしレアライザーの登録機能

CorDapp の開発者は、Flowフレームワークのチェックポイントの一部として、ある型をシリアライズする際に使用される、特定の型のカスタムシリアライザを作成することができるようになりました。

これは高度な機能であり、チェックポイントのシリアライズ中に例外を投げる特定の型に向けて特別に設計されていることに注意してください。大多数のクラスでは、カスタムシリアライザは必要ありません。

カスタム・チェックポイント・シリアライザは、新しいCheckpointCustomSerializerインターフェースを実装することで作成されます。

詳細については、「CorDappチェックポイント用のプラグ可能なシリアライザー」を参照してください。

復帰不能なCheckPointを自動検出する機能

CheckPointに到達すると、Flowは自動的にシリアル化された後、デシリアライズされるようになりました。これにより、デシリアライズできないCheckPointを作成するFlowコードを効率よく検出できるようになりました。これは、開発者やネットワークオペレータがCorDappsを開発する際に、復帰不能なCheckPointを検出できるようになるため、適切に再試行できないFlowを書くリスクを減らすことができます。

この機能は、開発者が共通で直面する以下のような問題に対応しています。

Kryo（Cordaが使用しているCheckPointシリアライズライブラリ）で正しくシリアライズ/デシリアライズできないオブジェクトを作成したり、データ構造を活用したりすること。
べき等性がない、または動作を重複排除しないFlow（外部システムへの呼び出しなど）を書くこと。

この機能は、エラーが発生しなくても、CheckPointからFlowをリロードする方法を提供します。その結果、開発者は、Flow全体に復帰可能なエラーを注入する方法を必要とせずに、Flowが正しく動作することをより確信できるようになります。

この機能は本番環境では使用すべきではありません。設定ファイル(node.conf)ではデフォルトで無効になっています。

reloadCheckpointAfterSuspend = false

詳しくは、「修復不可能なCheckPointの自動検出」を参照してください。

DockerformのホストからコンテナへのSSHポートマッピング

Dockerコンテナを作成する際に、ホスト上のSSHポートをコンテナ上の同じポートにマッピングできるようになりました。詳細については、「ローカルでノードを作成する」のオプション設定を参照してください。

メータリング収集ツールのメータリングクライアント

カスタムクライアントを構築したり、シェルにアクセスしなくても、Corda Enterprise Nodes からメータリングデータを収集できるようになりました。詳細については、「Metering Collection Toolのメータリングクライアント」を参照してください。

Notaryリストのホットロード

Notaryリストをホットロードできるようになりました。Notaryネットワークパラメータを更新しても、Nodeをシャットダウンして再起動する必要はありません。詳細については、Networkmapのホットローディングを参照してください。

ファイアウォールなしでのHSMにNodeTLSキーを保存する機能

Nodeは、Corda Enterprise Firewall を実行していなくても、TLS キーを HSM に保存できるようになりました。このため、新しいオプションの tlsCryptoServiceConfig セクションが、ノード構成ファイルのenterpriseConfiguration 構成セクションに追加されました。

ファイルベースのNodeのTLSキーストアからHSMに移行するには、tlsCryptoServiceConfigセクションをnode.confに追加し、HA ユーティリティの更新に関するセクションで説明されているように、TLS証明書と鍵を更新する必要があります。

詳細については、「NodeTLSキーのHSMへの格納」を参照してください。

スタンドアロンの CorDapp として利用可能なLedgerGraph

LedgerGraphは、Collaborative Recover CorDappsなどの他のCorDappsが、Nodeのすべてのトランザクションとその関係性に関するデータにほぼリアルタイムでアクセスできるようにします。

LedgerGraph はすでにいくつかのソリューションで使用されていますが、今ではそれ自体が CorDapp として利用できるようになりました。したがって、オペレータとして、Flowと JMX/RPC を介して Corda 元帳に関連するインメモリ・トランザクション統計を公開するために、Node上のスタンドアロン・アプリケーションとして LedgerGraph を使用できるようになりました。

LedgerGraph が公開しているメトリックスには、以下のようなものがあります。

各トランザクションチェーンのサイズ（バイト数）と深さ。
各トランザクションチェーンで参照される添付ファイルの数。
トランザクションチェーンのすべてのアウトプットが消費されたかどうか。

Collaborative RecoveryのV1.1へのアップグレード

LedgerGraph がスタンドアローンの CorDapp として利用できるようになったため、この変更を反映して Collaborative Recovery CorDapps がアップグレードされました。Collaborative Recovery V1.1を使用するためには、対応するLedgerGraph CorDappがインストールされている必要があります。コラボレーティブリカバリーで機密情報を使用する場合、V1.1ではこれを処理するようにLedgerGraphを設定しなければなりません。V1.0では、Confidential Identitiesの設定をLedgerSync CorDappに追加する必要がありました。

CockroachDBのパフォーマンス向上

新しい設定フラグが導入され、CockroachDB用のネイティブSQLを複数行挿入文で利用できるようになりました。

詳細については、「Configuration fields」を参照してください。

NotaryデータのCockroachDBへの移行

Perconaのデータベースに保存されているNotaryのデータをCockroachDBに移行できるようになりました。

詳細については、「PerconaのNotaryデータをCockroachDBにインポートする」を参照してください。

Notaryのアイデンティティ設定

NotaryNotaryを登録する際には、新しいフィールド notary.serviceLegalName を定義しなければなりません。これにより、シングルNotaryをHA Notaryにアップグレードすることができます。

詳細については、「Notaryサービスの概要」を参照してください。

スタンドアロンのJPA Notaryの最適化

新しい設定フラグ、notary.jpa.generateNativeSQLを追加しました。このオプションを notary.jpa.generateNativeSQL = true に設定すると、複数行のinsert文を持つ Cockroach DB 用のネイティブな SQL を生成することができます。これにより、場合によっては、insertクエリの数とサービスの待ち時間を減らすことで、Notaryのパフォーマンスが向上します。

Nodeメンテナンスモード

Corda Enterprise NodeのオペレータがNodeのメンテナンスウィンドウをスケジュールする方法が追加されました。メンテナンスウィンドウの間、Nodeは以下のように設定できます。

RPC監査テーブルをクリアします。
メッセージIDテーブルをクリーンアップします。

メンテナンスウィンドウは、最上位の構成セクションであるenterpriseConfiguration の中の新しいオプション maintenanceMode 構成フィールドを使用して、Node構成ファイルを介してスケジュールすることができます。Nodeがメンテナンスウィンドウをトリガーまたは完了するたびに、記述的なログエントリが発行されます。

詳細については、「Nodeメンテナンスモード」を参照してください。

メッセージIDのクリーンアップの頻度を設定をする機能

Corda Enterprise は、以前に処理されたメッセージの識別子を含むテーブルの、より安全なクリーンアップを実行するようになりました。このクリーンアップ機構の頻度を制御するいくつかのパラメータを調整することもできます。そのためには、Node構成ファイルの enterpriseConfiguration セクションの processedMessageCleanup フィールドを使用します。

attachments クラスローダのキャッシュサイズの設定オプション

Node構成ファイルの新しい EnterpriseConfiguration 構成フィールド attachmentClassLoaderCacheSize を使用して、attachments クラスローダのキャッシュサイズを設定できるようになりました。このキャッシュは、トランザクションの添付ファイルを格納するために使用されるクラスローダーをキャッシュします。デフォルト値は、キャッシュあたりの添付ファイル数が 256 です。

デフォルト値は、R3サポートから明示的に指示がない限り変更してはいけません。

デプロイメント

Corda Enterprise FirewallとすべてのCorda Enterpriseセットアップツール用のDockerイメージ

現在、Corda Enterpriseのセットアップに必要なツール用のDockerイメージをリリースしているのと同様（https://hub.docker.com/r/corda/enterprise-setup)、Corda Enterprise Firewall用のDockerイメージをリリースしています（https://hub.docker.com/r/corda/enterprise-firewall）。当社のDocker Hub（https://hub.docker.com/u/corda）には、Corda Enterpriseの本番環境でのデプロイに必要なDockerイメージが含まれています。

その他の変更点・改善点

サードパーティの依存問題を避けるために、Corda Enterprise バージョン 4.4.3、4.5.1、4.6 では、サポートされている H2 Database Engine のバージョンを 1.4.197 に戻しました。
脆弱性のリスクを軽減するため、Corda Enterprise Firewallコンポーネントで使用しているApache Zookeeperのバージョンを3.5.4-Betaから3.61にアップグレードしました。詳細はApache ZooKeeperの設定を参照してください。
commons-beanutils をバージョン 1.9.4 にアップグレードし、セキュリティを向上させました。
Corda Enterprise 4.6 以降、DemoBench のサポートは廃止されました。
Accounts SDK の新しいマイナーバージョンであるバージョン 1.0.2 をリリースしました。このバージョンには、Corda Enterprise 4.6 との互換性を高めるデータベースの改良が含まれています。Corda Enterprise 4.6 で Accounts SDK を使用する場合は、Accounts SDK V 1.0.2 を使用する必要があります。
Tokens SDK の新しいマイナーバージョン - V1.2.1 をリリースしました。このバージョンには、Corda Enterprise 4.6と互換性を持たせるためのデータベースの改良が含まれています。Corda Enterprise 4.6 で Tokens SDK を使用する場合は、Tokens SDK V 1.2.1 を使用する必要があります。
ドライバDSLを使用して新しいドライバを起動する場合、NotaryNodeは、startNodesInProcessドライバプロパティに関係なく、ドライバを実行するのと同じJVMプロセス内のスレッドとしてデフォルトで起動します(startNodesInProcessがfalseの場合は新しいプロセスとして起動しません)。この設定はオーバーライドすることができます。テストがNotaryと通信し、Notaryが新しいプロセスとして実行されることを望む場合、startInProcessをfalseに設定する必要があることに注意してください。
Corda Enterprise 4.6 では、CorDapp の minimumPlatformVersion がNodeのプラットフォームバージョンよりも高い場合、CorDapp はロードされず、Nodeは起動に失敗します。これは、Corda Enterprise 4.5 の場合、このような条件でNodeが起動し、CorDapp をロードできなかったことがログに記録されていましたが、この動作が変更されました。詳細はバージョニングを参照してください。

プラットフォームのバージョン変更

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 モードでノードを実行して、不足しているコア・スキーマの変更を更新します。:java -jar corda.jar run-migration-scripts --core-schemas
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 フラグを使用してください。
--initial-registrationについては、「ノードのコマンドラインオプション」と「互換ゾーンへの参加」で説明しています。

問題の修正

FutureXプロバイダがHSMとの接続を確立しようとしたときにjavax.security.auth.login.LoginExceptionを投げる問題を修正しました。
ネットワークマップサービスが実行されていないと、devモードのCordaNodeが起動しない問題を修正しました。
Flows がエラーになっているにも関わらず net.corda.node.flows.FlowRetryTestテストに失敗する問題を修正しました。
Corda Enterprise 4.5.1からデータベース管理ツールでアップグレードした際に、node_metering_data_pkeyの一意の制約に関する予期せぬエラーが発生する問題を修正しました。
Flowドレインモードが有効な場合に、RPC startFlowが既存のクライアントIDFlowに再アタッチできない問題を修正しました。
Health Survey ToolがNodeのアルテミスブローカーとの接続を確認できない問題を修正しました。
FlowSessionCloseTest.flowが、グレイスフルに処理されたクローズでない限り、クローズしたセッションにアクセスできなかった問題を修正しました。
再起動時にsenderUUIDが設定されていないためにRetryFlowMockTestが失敗し、早期終了セッションメッセージのために受信Flowがハングアップされない問題を修正しました。
Cordaが起動エラーのエラーメッセージをログファイルに書き込まない問題を修正しました。
Liquibaseスキーマを使用しないカスタムCorDappsで実行されたログで、期待されたerror_code="5"エラーがログに出力されない問題を修正しました。
カウンターパーティがビジー状態の場合に、NULLエラーとスタックトレースでFlowが失敗する可能性がある問題を修正しました。
キルされたクライアントIDのFlowと他のステータスを持つFlowとの間で一貫性のない動作をする問題が修正されました。
pause-all-flows フラグなしで Corda Nodeを再起動すると、NodeがFlowドレインモードのままになり、モードが手動で無効になるまでFlow処理が一時停止してしまう問題を修正しました。
1つのHSMでTLSキーを使用するように設定された複数のNotaryを登録できない問題を修正しました。
使用したtlsCryptoServiceConfigの設定情報をHAユーティリティがログに記録しない問題を修正しました。
rpcAuditDataRetentionPeriodで月と年がサポートされていなかった問題を修正しました。
senderRetentionPeriodInDaysが負の整数に設定されている場合にNodeのシャットダウンに失敗する問題を修正しました。
Corda4.3で動作していたCorDappsが、Cordaを4.5にバージョンアップした際に登録されない問題を修正しました。
tlsCryptoServiceConfig.cryptoServiceConfファイルのパスが正しく解決されず、Nodeの登録時にエラーが発生する問題を修正しました。
Corda Health Survey Toolでは、ネットワーク情報が解決され、HTTP リダイレクトが発生した場合に警告メッセージが表示されるようになりました。
Nodeのシャットダウン時にメッセージでエラーが発生していた問題を修正しました。（メッセージ：The configuration values provided for message cleanup are invalid.）。
Health Survey Toolのテスト中にアルテミスがシャットダウンされた際に、すべてのチェックを実行した後にCordaのHealth Survey Toolがハングアップしてしまう問題を修正しました。
HSMが利用できない場合のエラーメッセージが表示されるようになりました。
CRaSH FlowクエリでDataとTime情報が正しく表示されるようになりました。
ClassGraph() フィルタ関数に渡されたクラスパス要素からオプションの file:prefix が取り除かれ、その結果フィルタ関数がその要素を認識しないという問題を修正しました。
StateMachineManager.startデータベーストランザクションがまだ開始されていない場合にFlowの実行を開始する問題を修正しました。
バージョンアップしたバージョンでR3のToolsが正常に動作しない問題を解決するため、Jackson 2.9.7に戻しました。
Paths.get(""")が現在の作業ディレクトリではなくnullを返す問題を修正しました。
web-4.6-RC05-thin.jarで、以下のエラーが発生し、IRSデモ用のサンプルWebアプリが実行できない問題を修正しました: no main manifest attribute, in web-4.6-RC05-thin.jar.
現在のイベントが長時間実行されたために次のメンテナンスイベントがトリガされなかった時、スリープタスク実行後に警告が表示されるようになりました。
RPC ユーザーのパスワードが間違っていた場合に、以前は処理されなかった例外が正しく処理されるようになりました。
DBへのアクセスに問題があって以前は処理されていなかった例外が、HikariPool.PoolInitializationExceptionとして扱われるようになりました。
CorDappクラスを使用した場合、クラスローダがクラスを見つけられない問題を修正しました。
ネットワーク・パラメータのパスが設定可能になり、ネットワーク・パラメータ・ファイルがNodo congfigurationで指定した場所に保存されるようになりました。

既知の問題

設定がツールのルートディレクトリにある場合、HA Utilities toolとHealth Survey Toolは、設定を使用するコマンドを正しく処理しません。
現在、Kotlin CorDapp テンプレートを Corda Enterprise 4.6 でビルドすることはできません。
KotlinおよびJava CorDappのテンプレートの間には、コードスタブと実際のコードに不整合があります。
Database Manegement ToolとCorda Enterpriseは、コマンドラインインターフェイスのオプションと設定ファイルでは同じ設定では動作しません。
HSMにアクセスできないために最初の試行が成功しなかった場合、Nodeは2回目の登録試行でHSMに接続しません。
ローカルネットワークブートストラッパーの使用には、以前のバージョンの Corda よりも時間がかかります。
FlowRPCOps RPCインターフェースの“new” operationは、StateMachineIDを引数に取るため、繰り返し呼び出しが発生します。
Nodeの一方がIdentity Managerサービスにアクセスできず、その結果、CRL配布ポイントにアクセスできない場合、2つの Node間でSSL接続を確立することはできません。
devModeOptions.allowCompatibilityZone=true がNode設定に追加されていない限り、Nodeは --dev-mode オプションでは実行できません。
Corda はログを作成できない場合、明確なエラーメッセージを表示する代わりに例外をスローします。
HA Utilitiesでは，notary-registrationオプションでCSRの詳細をログファイルに書き込みません。
the Attachment Demoでは、runSenderタスクはノータライゼーションのためにserviceLegalNameの代わりにmyLegalNameを使用します。
一部のサンプルは、ファイル名が長いという問題のため、Windowsでは実行できません。
dataSourcePropertiesが別ファイルにある場合、Database Manegement ToolはCorda Enterprise 4.6では動作しません。
シェルコマンドラインインタフェースを使用してMembershipStateを照会しても、ビジネスネットワークのロールは表示されません。また、シェルコマンドラインインターフェイスを使用して参加者のロールを変更することもできません。
定数 Instant.MAX および Instant.MIN を使用して FlowStart でFlowをフィルタリングすると、例外が返されます。
SSH クライアントは gracefulShutdown を実行した後、エラーが発生したことを示す一貫性のない終了コードを返します。
DockerNodeはTestnetに対して設定と証明書を生成しません。
Nodeは、証明書が失効したNodeからの着信したP2P 接続を警告とエラーで拒否しますが、再確立しようとする試み自体はブロックしません。これにより、Nodeのログファイルに警告やエラーが蓄積されてしまいます。
組織名(O)に禁止文字を含むNodeを登録しようとすると、コンソールでエラーテキストが繰り返されます。
CordaNodeの<install-shell-extensions>サブコマンドはホームフォルダにログファイルを作成し、他のすべてのサブコマンドはlogsサブフォルダにログファイルを作成します。
HA Utilitiesを使用しているときに，Notary登録に失敗すると，ダミーのNotaryキーストアファイルが作成されます。ユーザがこのキーストアファイルが作成されたことに気づかないと、再度Notary登録をしようとしたときに問題が発生します。

・・・・・・・・・・・・・・・・・・・・・・・・・・

Facebook： m.me/R3DLTJapan
Twitter： SBI R3 Japan(@r3sbi)
HP： https://sbir3japan.co.jp/

このセクションの記事