2

I need to retrieve all packages installed into organization along with their contents (i.e. classes, objects etc.). But different org could have different packages installed.

I was going to use ant's sf:retrieve target for this. But the problem is: I can't just hardcode list of package names into packageNames param.

It looks like at first I need to get list of installed package names. I've tried already different approaches to get full package name, i.e. sf:listMetadata, sf:describeMetadata, sf:bulkRetrieve, retrieve objects and parse their names. But in all these cases I could get only namespace prefix or package version, but no full name.

And unfortunately, sf:retrieve's packagesName doesn't work with namespaces (which is really frustrating for me).

Maybe someone from community has already encountered with such problem (or maybe even solved it). Any help would be appreciated.

Thanks in advance.

1
  • If you make an idea exchange post for this I'll make sure the product manager for the metadata API sees it. Now that you bring it up this does seem to be missing from any api. Commented Jul 3, 2016 at 16:57

1 Answer 1

1

I've done a lot of work automating package installation/upgrade/delete through the InstalledPackage metadata type and I'm not aware of any way to actually get the package names. Packages themselves are not exposed through the Metadata API, just InstalledPackages which contain only a namespace and a version.

The only way I can think of that you could get the package name would be to use Selenium to connect to the org and scrape the package names through the UI. We use Selenium for a somewhat related use case where there is no API: uploading beta managed packages. If you need to go this route, you could use our package upload selenium script as a guide:

https://github.com/SalesforceFoundation/CumulusCI/blob/master/ci/package_upload.py

However, it might be possible to use the Tooling API to query for some metadata by namespace. I verified that you can query classes and objects through the Tooling API by namespace prefix. However, you'd have to script the whole interaction for each metadata type.

3
  • Thanks, Jason. I was trying to avoid 'web scraping', but looks like it's the only way to go for me. It's really strange that SF guys don't provide access to package name, but still require it as parameter for metadata retrieve call. It would be smart to extend metadata api with retrieve by namespace method for packages. Eh, it's just my dreams) Some SF glitches make me really nervous)
    – wesaw
    Commented Jan 29, 2015 at 16:47
  • I totally understand the desire to avoid web scraping. I don't like using Selenium in our use case, but it does work pretty reliably for us. However, I think you can get at what you want through the Tooling API as noted in the answer. It would just require some scripting. You wouldn't get the same thing as you'd get from the MDAPI, but you can't get the contents of classes from managed packages anyhow. Commented Jan 29, 2015 at 17:03
  • Yep, you are right about classes from managed packages, the source code is hidden anyway. The main idea of my quest is to build kinda usage statistics, i.e. for each field identify list of formulas, layouts, workflows where it's used. That's why retrieving all packages at once through MDAPI in the form of xml files is very convenient for me. No need to make couple calls for each field or package, and it's relatively easy then to gather all necessary info from retrieved bunch of xmls. Tooling API approach doesn't look quite good due to huge amount of info to be fetched individually & analyzed.
    – wesaw
    Commented Jan 29, 2015 at 18:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .