3

I need to create an AppExchange Package (extension to Health Cloud), which has dependencies on the Health Cloud package.

As per documentation/community, 2GP is the recommended way to package new applications. As mentioned in the steps in the below link (step number 3), we need to create a scratch org and develop the app on the scratch org. https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_workflow.htm

In my case, the App has a dependency like Health Cloud Package. I assume we need to write automation scripts that will install the required packages in the scratch org, then we need to do the development and packaging.

I think technically it is possible to create a 2GP extension package with dependent packages like Health Cloud, Field Service Lightning, or Financial Service cloud.

Question: Can someone please suggest, if 2GP is recommended/feasible if the package has dependencies on 3rd party packages like (Health Cloud, FSL, FSC, etc.)?

3

It's definitely possible to create 2GP dependent packages where the Parent Package is Health Cloud, FLS, or any other Managed/Unlocked package app.

You will need the Health Cloud Package to be installed in scratch org for this and you need below in your project sfdx-project.json file. Here "04t..." will be the latest Health cloud package ID.

Check the dependencies section docs for more info

"dependencies": [
        {
            "subscriberPackageVersionId": "04t..."
        }
    ],

Also additionally you will need to make sure you have the necessary feature and settings enabled in your project-scratch-def.json file

For example, for Health Cloud you will need the below features

"features": ["ContactsToMultipleAccounts", "HealthCloudUser"]

Watch this session to see how dependent packages work.

Also, I wrote a blogpost on how to approach it here

2

The answer is yes, absolutely.

Unfortunately the Scratch Org creation mechanism isn't yet smart enough to deal with this for you and Salesforce suggested writing scripting to deal with installing the dependency packages. This is covered here.

We did it somewhat differently. We "extended" the sfdx-project.json (in a completely compatible manner) to add the installation keys for the dependency packages, which themselves must already be listed as dependencies anyway. So we have something like:

{
  "namespace": "namespace",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "50.0",
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true,
      "package": "My Package",
      "versionNumber": "1.0.1.NEXT",
      "versionDescription": "Something about My Package",
      "ancestorId": "My Package@1.0.0",
      "definitionFile": "config/some-scratch-def.json",
      "postInstallScript": "namespace.SomeInstaller",
      "dependencies": [
        {
          "package": "Other Package@2.2.0"
        },
        {
          "package": "Another Package@5.10.4.1"
        }
      ]
    },
    {
      "path": "force-unpackaged"
    }
  ],
  "packageAliases": {
    "Other Package@2.2.0": "04t0N00000XXXXX",
    "Other Package@2.2.0:key": "Some Password",
    "Another Package@5.10.4.1": "04t4P00000XXXXXXXX",
    "Another Package@5.10.4.1:key": "Some Other Password",
    "My Package": "0Ho3Z000000XXXXXXX",
    "My Package@1.0.0": "04t3Z00000XXXXXXXX"
  }
}

Note that the packageAliases contains extra entries with the "key" (the installation key/password) for the dependency packages. In our case we depended on another of our own packages ("Other Package") and a third party one ("Another Package") in order to integrate the two.

We had to negotiate with the third party and persuaded them to provide us access to a beta of their package. That way we could do the install on scratch orgs, but we could not make use of their package on production orgs.

We wrote scripting (actually Ant but it could have been anything else) executed when creating the Scratch Org before anything is pushed that found the dependencies using the sfdx-project.json content and did the installation using the sfdx CLI.

In this case it actually takes about an hour to create the scratch org, because the installations take so long (both are big 1GPs that we must install before doing anything with the 2GP extension package). As such we tended to keep these scratch orgs longer than normal and would use them for multiple development tasks - normally we create a scratch org per development task, since it takes about 10 minutes (both creation and initial package metadata push) but that's not feasible here with the lengthy delay for these installs.

As always, the scratch def JSON file needs to be appropriate to ensure the features required by the third-party package(es) are enabled.

Note, too, that there is a (safe harbour) future Salesforce feature called "Scratch Org Snapshots" (search for "snapshot") that may help here - you create a snapshot from an org with the two packages already installed and the scratch org creation using that snapshot is then faster, but it is not currently top priority in the managed package team at Salesforce sadly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.