AppLink resource avec Oracle Docs
Last modified on October 2, 2026 • 5 min read • 965 wordsObjet
Oracle Documents Cloud Service peut être proposé dans une solution de type B2B, avec un mode particulier de fonctionnement (Applink) qui preserve l’ergonomie général au sein d’une application externe tout en offrant un coût d’usage raisonnable
Use case
Applink représente un ensemble d’APIs REST dont l’objectif est de donner accès à un dossier ou bien un fichier dans le contexte d’une application, et non pas par un mécanisme de partage. L’accès aux objets est ainsi prévu pour une durée limitée de temps.
Au point de vue interface, cela ressemble beaucoup au mécanisme EMBED, c’est à dire que l’affichage sera effectué dans une iframe.
Applink ouvre un champs important d’applications possibles et résout principalement un problème économique pour les contextes B2B : portails fournisseurs, par exemple, ou portails clients.
Bilan économique
Prenons l’exemple d’une compagnie réalisant son portail pour ses 2.000 fournisseurs. La compagnie veut proposer pour chacun d’eux, une zone d’échange par l’intermédiaire d’un dossier dédié, dans lequel le fournisseur pourra à la fois lire mais aussi uploader des documents.
Dans notre exemple, il n’y a pas de besoin identifié de synchronisation mais seulement de partage de type 1:n (et non pas n:n comme dans une véritable environnement collaboratif)
Si on propose une souscription pour 2.000 comptes, le besoin fonctionnel est largement couvert (très au delà de ce qui est demandé), mais ce mode de tarification induit deux problèmes :
- Chaque fournisseur a connaissance de l’existence de tous les autres puisque la fonction de partage lui permet d’avoir accès à l’annuaire de l’identity domain. Cela peut être rédhibitoire.
- Le coût est élevé : 2.000 x 13€ = 26.000 € /mois soit 312.000€/an
En comparaison:
- l’usage des APIs Applink supprime le premier problème de confidentialité (pas de partage possible avec d’autres membres)
- et ramène le coût à un niveau très bas pour le client (et pour Oracle aussi …) . Le coût est alors de : 10 x 13€ = 130€/mois, soit 1.560 €/an
Considérations techniques
Principe
L’application hôte (portail en PHP, ou Apex ou .NET etc.) doit faire un premier appel REST afin de générer un applink.
Lors de ce premier appel, le périmètre d’un applink concerne:
- Un dossier ou bien un fichier (identifié par un ID unique. ex: dossier dédié à un fournisseur)
- Est accordée à un utilisateur (déjà membre. On utilisera un seul membre qui sera le owner de TOUS les dossiers)
- Un rôle attribué tout au long de la session (contributor, viewer, downloader)
La durée d’un applink est de 24h avec un rafraîchissement possible toutes les 15 minutes.
Questions en suspens sur l’implémentation technique
L’affichage de l’interface est effectué dans une iframe qui , pour des raisons de sécurité, déclenche un event qui doit être traité par la page parent, et celle-ci envoie en retour un token d’habilitation. Un des problèmes est la sécurisation de ce token. En effet, il faut éviter que le code javascript puisse être réutilisé en dehors du contexte de l’application hôte. Pour information, il n’y a pas de notion de domaine appelant certifié dans la liste de Docs, à l’instar de ce qui est fait pour les sites externes qui utilisent la fonctionnalité EMBED.
Échantillons d’interface
Ci-dessous le contenu de l’iframe qui est alimentée par l’appel à Applink.
La personne qui utilise Docs dans le contexte de Applink ne peut pas effectuer de partage avec un autre membre ! C’est pour cette raison que le cloisonnement est efficace entre les différents utilisateurs (beaucoup plus que dans le fonctionnement normal de Docs qui est de nature collaborative, par construction !)
Voici le dossier tel qu’il est affiché au owner . Observer l’ID du user pour l’image précédemment téléchargée. Cet ID correspond à celui de l’utilisateur auquel une délégation a été accordée dans le cadre du contexte de Applink.
Version de Juillet 2015
Resource Applink can be very useful for B2B contexts, for instance. This is a variant of embed interface which allows to give, for a specific duration of time, an access to a folder or a file to a registered user. The main feature is that the final user is not challenged for its password because this is the application which provides access to folder.
Here is a typical B2B scenario which we should like address with Oracle Docs, but we are facing a kind of deadlock .
A company want publish all invoices for its 2000 customers. These invoices (pdf format) will be in view mode only. (no need for upload or sync or sharing)
It’s a One to Many model. We intend to propose Oracle Docs.
BUT ware are facing the following dilemma:
| Usage of Oracle Docs | Revenue | pro | Cons |
|---|---|---|---|
| If we license 2000 members | HIGH | All features are available. | Each customer can see the existence of all others (because of sharing features). This is a showstopper for a B2B usage. |
| If we license minimum (25) | VERY LOW | We cover the need (no less, no more) by providing a public link access to a dedicated folder | We need to add a password access and this can’t be provisioned by REST Apis nor setup by customer itself. |
And there, AppLink could be interesting
Some points to note:
- landing pad is the folder itself
- User cannot change its profile
- User cannot share documents (even if he is given contributor role)
Benefits of this approach
Let’s assume a B2B context where there are 2000 customers
We can build a solution where we price 2000 members without the risk that a member see other members in the domain directory. It will be a strict APPLICATION scope usage, without collaborative features.
Credentials will never given to the members because access will be controlled by application itself.
Resources: