Loading
Salesforce から送信されるメールは、承認済ドメインからのみとなります続きを読む

廃止された Visualforce を管理パッケージから削除する

公開日: Oct 13, 2022
説明
背景情報: Spring '15 では、フレキシブル管理パッケージイニシアチブの一環として、私たちは公開管理パッケージからの Visualforce (ページ、グローバルコンポーネントおよび静的リソース) の削除を有効にしました。これは管理パッケージの所有者が廃止した VF を取り除くのに役立つはずです。

(フレキシブル管理パッケージは、公開管理パッケージからのコンポーネントの削除を可能にするイニシアチブです。現在まででサポートされるコンポーネントの種類は、カスタムタブ、項目、オブジェクト、入力規則、レコードタイプ、項目セット、ボタン、リンク、VF ページ、グローバル VF コンポーネント、静的リソースです。)

Spring'15 のリリース間近になって、これまでに考えたことがなかったシナリオがあることが分かりました。そのシナリオについて説明する前に、パッケージ化に関連した Apex の動作を説明しておきたいと思います。


Apex とパッケージ化: Apex と VF がパッケージ化可能になって以降、公開 Apex クラスと公開 VF コンポーネントは公開管理パッケージから削除可能になりました。パッケージ化組織で公開 Apex クラス/VF コンポーネントを削除すると、そのパッケージのバージョンのアップグレード時に登録者組織でも同じものが削除されます。このプロセスでは登録者は何の役割も果たしません。
フレキシブル管理パッケージイニシアチブの策定時には、登録者組織のメタデータを削除することは考えていませんでした。たとえば、パッケージ化組織でカスタム項目や入力規則を削除すると、アップグレード時に、登録者組織ではこれらの「削除済み」コンポーネントに「削除」ボタン/リンクが表示されます。これにより、登録組織のシステム管理者は影響を分析し、必要に応じて削除するものを決定することができます。Salesforce では一貫してこのモデルを保持しており、登録組織で VF (ページ、グローバルコンポーネント、静的リソース) が削除された場合でも、
メタデータを削除することはせずに、[削除] ボタンを有効にするようにしています。

矛盾: 上記の結果として、1 つの矛盾が生じます。アップグレード時に登録組織で公開 Apex クラスと公開 Visualforce コンポーネントが削除されても、Visualforce ページとグローバル VF コンポーネントについては同じことは行われません。(これはすべて登録側の動作です。パッケージ組織では、いずれかを削除すると、永久的に削除されます)。討議を重ねた結果、用心には用心を重ねる (フレキシブル管理パッケージイニシアチブの一環として登録組織でメタデータを削除しない) ことを優先し、この矛盾を甘受することになりました。

シナリオ: さて、ここから問題のシナリオの説明です。まずは単純なシナリオの一例を挙げます。公開 Visualforce コンポーネント「pc1」を参照している Visualforce ページ「p1」があるとします。パッケージの 1.0 では、p1 => pc1 です。バージョン 1.1 で、p1 を削除することにします。Salesforce があなたのお客様を 1.0 から 1.1 にアップグレードできるようにしたとします。これをサポートする上での問題は、
登録組織がアップグレード後に、たとえ可能であっても p1 を削除しない可能性があることです。パッケージ化組織ではもう p1 はありませんから、パッケージから pc1 を削除しない理由がありません。pc1 を削除して、パッケージのバージョン 1.2 をリリースしたとします。登録者が 1.2 にアップグレードすると、Visualforce ページ p1 はアップグレード時に削除された pc1 に依存するため、読み込めないという結果になります。p1 がビジネスにとって重要な Visualforce ページであった場合、お客様は重大な機能の中断を経験することになります。

 
解決策
修正: この問題を未然に修正して、登録者組織の Visualforce ページやグローバル Visualforce コンポーネントが壊れないようにするために、次のようなソリューションを考案しました: アップグレード時 (この例では、1.0 から 1.1 へのアップグレード時) に、状況が [削除済み] で、かつ公開 Apex または Visualforce コンポーネントを参照している Visualforce ページまたはグローバル Visualforce コンポーネントがないかどうかをチェックします。「ある」場合は、アップグレードをブロックして、お客様の Visualforce が破損するのを防止します。

パートナー側での対応: それでは、パッケージアップグレードが壊れないようにするには、どうしたら良いでしょうか? この例の場合は、1.0 からパッチバージョン 1.0.1 を作成します。1.0.1 で、Visualforce ページ p1 を編集し、pc1 への参照を削除します。バージョン 1.0 を使用しているお客様を (転送機能を使用して) まず 1.0.1 にアップグレードし、次に 1.1 にアップグレードします。これにより、バージョン 1.0.1 の pc1 への p1 の参照が削除されます。こうすれば、1.1 にスムーズにアップグレードできます。2 段階のプロセスになってしまうことは面倒ですが、この制約を課すことで、お客様側でアプリケーションの不具合が生じることを防止できます(さらに、パッケージ化組織で Visualforce ページや Visualforce コンポーネントを削除しようとすると、この 2 段階プロセスを思い出してもらえるように警告メッセージが表示されるようにしています)。


第一世代管理パッケージからのコンポーネントの削除
Edit Visualforce Page in a Managed package (英語)
ナレッジ記事番号

000387314

 
読み込み中
Salesforce Help | Article