Adobe Illustrator custom protocol handler adbai://

[Emanuele33904507jyus]

Hi, we are implementing a feature in one of our applications (called PLM) that requires interactions with Adobe products, mainly with Adobe Illustrator.

Below a description of the specific case.

Pre-requirements

1) The final users have installed on their local machines Adobe Illustrator or Adobe Photoshop (or both...)

2) The final users use the Adobe applications to work on files stored in a shared local folder.

3) The specific file, be it ai or ps, is then associated to some additional data (eg specific product info/data) managed by our PLM application.

4) Our PLM application is a web application, running in a standard browser.

Our customers would like that:

1) the final user, in the web PLM application, navigates to the product info page of a specific product using their browser

2) the product info web page contains a link to the associated local Illustrator or Photoshop file

3) the user clicks on the link and the PLM application automatically opens the correct Adobe product with the associated local file (Illustrator or Photoshop)

After some investigations, we found that Adobe installs two custom protocol handlers to interact with the locally installed applications

a) for Adobe Illustrator: adbai://

b) for Adobe Photoshop: adbps://

We have found that if we call these custom protocols from a web page, the correct Adobe application opens.

Are there any parameters that we can put in the custom protocol URI, so that we can pass the full path of the local file, and have the Adobe Illustrator or Photoshop open it?
Is there some documentation on these custom protocol handlers?

[hhas01 · Accepted solution]

The Creative Cloud app uses the adbai/adbps/etc protocols to open cloud files, e.g.:

adbai://app?action=openCloudDoc&cloudURL=https%3A%2F%2Fcc-api-storage.adobe.io%2Fid%2Furn%3Aaaid%3Asc%3AEU%3A316f34a7-c189-479c-938d-c54d95675c6b%3Fpath%3D%252Fcloud-content%252Ftest.aic&confirmAccess=false&displayName=test.aic&mv=product&mv2=accc

There does not appear to be public documentation of the protocol, though you’d need to go rummage the CC developer docs to be sure. I have no idea what Adobe Cloud provides for third-party integration. (I’m guessing for starters that Adobe will want customers to store all their files in Adobe Cloud, not on their own local servers/shared folders.)

If the files always have .ai/.psd extensions, you could use the standard `file:///path/to/file` protocol and associate AI/PSD in the web browser to open those types. But I’m guessing you’ll want to open .pdf and other file types too, and avoid any risk of problems due to manual misconfiguration.

You might be best implementing your own Mac/Win protocol handler app that runs in the background and interacts with Adobe’s apps via local IPC You can then define whatever protocols you need. The downside is it’s another third-party app which customers must install, but it’s a technically straightforward solution using public documented APIs. This’d also give you the option of making file management/integration more robust, e.g. copying a file to local HD while the user works on it, then copying back to the server when done, with change tracking and so on. (Users working directly on network shares makes me  a bit squicky, although it is how a lot of studios traditionally roll.)

[Emanuele33904507jyus]

Thanks for the suggestions!

We checked the creative cloud links as you have shown, and it seems to be promising, since there is an action called openCloudDoc and a parameter called cloudUrl. The cloudUrl parameter cointains the urlencoded uri of the resoure (https://cc-api-storage.adobe.io/id/urn:aaid:sc:EU:316f34a7-c189-479c-938d-c54d95675c6b?path=%2Fcloud...). However there is no documentation on an action to open local files. We cannot implement a feature basing on something that is not public.

We are also internally evaluating a separate custom protocol handler, which would work exactly as you have described. 
The drawback of this approach is the additional configuration on the user machine, with a third party kit to be installed.
And also the fact that the configuration is different on windows and mac. At least however it is something that can be managed, and later on evolved towards a more native cloud system.

We also evalutated the file protocol, but we decided not to go down that way, because it is being deprecated from most browers.

In terms of the file share, currently the requirement of not using a cloud solution is a hard requirement from the customer, due to the business sensitivity of the files. As for the users working on network shares, it's exactly how the customer works. In the PLM application we have partial support for a sort of versioning system to workaround the problem. Ideally I would prefer a native cloud blob storage with all the attached features, but that's a no-go (for now at least).