サードパーティのシステムからのデータは、プロキシオブジェクトを使用することで、DXPで管理できるようになりました。 顧客は、Liferayのローコードフロントエンドアプリケーションの構築機能を使用して、DXPでデータを表示するために、適切なSSOの実装と横断的なOAuth 2に頼ることができるようになりました。
重要: データはLiferayのデータベースで永続化されないので、プロキシオブジェクトにはいくつかの制限があります。詳しくはこちら。
Release Notes
サードパーティのシステムからのデータは、プロキシオブジェクトを使用することで、DXPで管理できるようになりました。 顧客は、Liferayのローコードフロントエンドアプリケーションの構築機能を使用して、DXPでデータを表示するために、適切なSSOの実装と横断的なOAuth 2に頼ることができるようになりました。
重要: データはLiferayのデータベースで永続化されないので、プロキシオブジェクトにはいくつかの制限があります。詳しくはこちら。
複数の環境にまたがるコンテンツの管理と同期が、より簡単で信頼できるものになりました。 このリリースで、Liferayは2つの強力な機能強化を導入し、バッチエンジンの機能を拡張しました:
外部参照コードによる一括削除 - 内部IDの代わりに外部参照コードを使用してアイテムを削除できるようになったため、一括削除がよりシンプルになり、環境間で一貫性が増しました。
削除のインポート・ストラテジーのサポート - バッチ削除を実行する際、ユーザーは操作を部分的(エラー時に停止)にするか、完全(一部のアイテムが失敗しても継続)にするかを定義できるようになり、プロセス中のコントロールとフォールトトレランスが向上しました。
これらのアップデートは、特に外部識別子に依存する環境や、ステージング、プロダクション、その他のインスタンス間で一貫したデータメンテナンスが必要な環境において、チームが一括削除を管理する方法を合理化します。
主なメリット:
より信頼性の高い環境同期: 外部参照コードにより、内部IDに依存することなく、異なる環境間で同じエンティティを削除できるため、ミスマッチのリスクを低減できます。
一括削除ワークフローの簡素化: 大規模なデータセットの削除がより簡単になり、手作業の手順が減り、エラーの可能性が低くなりました。
削除操作をより自由にコントロール: エラー時にプロセスを停止するか、完全に完了させるかを選択できるため、チームの運用ニーズに合わせて動作をカスタマイズできます。
回復力と耐障害性の向上: 削除ジョブが些細な問題で完全に失敗する可能性が低くなり、保守プロセスがよりスムーズになります。
エンティティ間の一貫したサポート: これらの機能強化は、バッチエンジンがサポートするすべてのエンティティタイプで利用できるため、さまざまなユースケースに幅広く適用できます。
バッチエンジンの各実行により柔軟性を持たせるため、新しいパラメータ(batchExternalReferenceCode)を追加し、インポートタスクのERCを更新せずにバックエンドに送信できるようになりました。
主なメリット:
目的ごとに1つのパラメータで実行できるので、実行が簡単です。
バッチをサポートするすべてのエンティティに新しい機能を追加します。
私たちは、SCIMプロバイダーの仕様(Microsoft Entra、Cyber Arkなど)を実装することで、最も関連性の高いSCIMプロバイダーを設定できるようにしました。
主なメリット:
トップクラスのアイデンティティ・プロバイダのSCIMエンドポイントを導入することで、自動化されたプロビジョニング、デプロビジョニング、およびプラットフォーム間でのユーザー・データの同期が可能になり、ユーザー管理が合理化され、セキュリティが確保されるようになります。 これにより、セキュリティが強化され、コンプライアンスが確保され、手作業が減り、一貫性とユーザーエクスペリエンスが向上します。 標準化された相互運用性により、将来的な統合を保証し、運用効率を高めると同時に、ID ライフサイクル・イベントの可視性と制御性を向上させます。
マルチテナント環境のニーズを満たすために、Captchaエンジンはインスタンスレベルで設定可能である必要があります。他のインスタンスの設定に干渉することなく、1つのインスタンスに対しての設定が可能でなければなりません。
主なメリット:
インスタンスレベルでCAPTCHA を有効にすると、グローバル設定に影響を与えることなく、柔軟な設定が可能になります。 これにより、カスタマイズされたセキュリティとユーザーエクスペリエンスをサポートし、インスタンスごとのコンプライアンスを実現します。
BETAフラグを有効にしなくても利用できるようになり、今後は正式にサポートされます。
メンテナンス期間中に問題が発生すると、エンドユーザーにはブランド化されていないデフォルトのメンテナンスページが表示されていました。そのため、ユーザーフローの一部が放置され、お客様はユーザーを適切な次のステップに誘導することができませんでした。DXPがダウンしている場合でも機能するメンテナンスページの設定と管理には、必ずしもすべてのお客様が備えているわけではない技術的なスキルが必要であり、多くのお客様にとって現実的ではありません。
お客様は、自社ブランドにマッチした、お客様への対応手順を記載したメンテナンスページを独自に設計し、アップロードできるようになりました。この実装はDXPインスタンスとは独立して機能するため、ダウンタイムを検知するとすぐに、クラウドコンソールのメンテナンスページをユーザーに表示し、ダウンタイムの原因となった問題に対処できるようになります。
Liferayのスケーリング動作の設定は単純ではありません。お客様は、閾値を設定するために、アプリケーションのメトリクスがどのように動作するかを深く理解する必要があります。また、時間やインスタンスの規模に応じて料金が発生するため、お客様は請求金額に戸惑うことになります。
そのため、クラウドコンソールのスケーリングページで、スケーリングするインスタンスの最大数と最小数を設定できるようにしました。これにより、技術に詳しくないお客様でも、アプリケーションのスケーリングに必要なコストを自由にコントロールできるようになります。これにより、インスタンス数の増加によるユーザーエクスペリエンスの向上と、それに伴うコストの増加とのバランスを、的確に判断できるようになります。