Si vous disposez d'instances Oracle Content Management exécutées sur une infrastructure cloud héritée avec un abonnement non mesuré, Oracle vous recommande de les migrer vers le nouvel environnement Oracle Cloud Infrastructure (OCI) natif, OCI Gen 2 (utilisation de la console Infrastructure pour gérer les instances de service). De cette façon, vous profiterez des avantages et des avancées à venir de la plate-forme cloud d'Oracle.
Pour lancer la migration, vous devez d'abord effectuer certaines étapes et la programmer avec le support technique Oracle.
Ce tableau décrit la correspondance des groupes de droits d'accès Oracle Content Management et des rôles d'application OCI.
Groupe de droits d'accès Oracle Content Management | Rôle d'application OCI |
---|---|
DocumentsServiceUser | CECStandardUser |
DocumentsServiceAdmin | CECServiceAdministrator |
SitesServiceVisitor | CECSitesVisitor |
SitesServiceAdmin | CECSitesAdministrator |
ContentAdministratorRole | CECContentAdministrator |
CECSStandardUser | CECStandardUser |
CECSEnterpriseUser | CECEnterpriseUser |
Remarque :
Si le domaine IDCS cible contient déjà un utilisateur portant le même nom, les rôles d'application OCI correspondant aux groupes de droits d'accès Oracle Content Management de l'utilisateur existant seront affectés à l'utilisateur.Lorsque vous êtes prêt à effectuer la migration, vous devez soumettre une demande de migration pour lancer le processus :
Une fois que le support technique Oracle reçoit votre demande de service de migration, nous programmons la migration en fonction de la date que vous avez demandée, et la demande de service est mise à jour avec la date et l'heure de début de la migration.
La demande de service est mise à jour afin de refléter la progression de la migration. La migration des données est effectuée en back-end : aucune action n'est requise de votre part en dehors de la consultation des mises à jour de la demande de service et de la validation de la migration une fois qu'elle est terminée.
Voici ce qui se produit pendant la migration :
Important :
A ce stade, vous ne devez apporter aucune modification à votre ancienne instance (source). Toute modification réalisée après le début de la migration n'est pas migrée vers la nouvelle instance.Remarque :
L'ancienne instance reste en fonctionnement pour que vous puissiez vous y référer à des fins de validation. Vous devez également migrer tous les sites qui utilisent des ressources et migrer toutes les autres ressources exclues lors de la migration.Si des intégrations ou communications étaient en place entre votre ancienne instance et d'autres services ou applications, que ce soit directement ou via des appels d'API REST, vous devrez peut-être effectuer des tâches post-migration.
Les éléments suivants s'appliquent à l'échelle du service :
Les anciennes URL utilisaient le modèle suivant :
https://<nom-service>-<nom-compte>.<région>.oraclecloud.com/documents
Les nouvelles URL utilisent le modèle suivant :
https://<nom-service>-<nom-compte>.<type-service>.ocp.oraclecloud.com/documents
Intégration | Opérations à effectuer après la migration |
---|---|
Oracle Integration |
|
Oracle Commerce Cloud |
|
Oracle Process Cloud Service |
|
Oracle Eloqua Cloud Service |
|
Oracle Intelligent Advisor |
|
Oracle Cobrowse Cloud Service |
|
Responsys |
|
Visual Builder Cloud Service (VBCS) |
|
CDN/Akamai |
|
Appels d'API REST |
|
Utilisation de CLI/SDK client |
|
Connecteurs |
|
Remarque :
Tous les signets sur le contenu de votre ancienne instance ne fonctionnent plus car l'URL de la nouvelle instance a changé.Les sites qui ne contiennent pas de ressources sont migrés automatiquement, mais pour ceux qui en contiennent, vous devez effectuer quelques étapes supplémentaires pour pouvoir les faire fonctionner dans votre nouvelle instance Oracle Content Management.
La commande "cec migrate-site" est nouvelle, vous devez donc installer OCE Toolkit à partir du référentiel Git WebClient même si vous l'avez téléchargé et installé précédemment.
Suivez les instructions indiquées sur la page Sites Toolkit pour télécharger et installer OCE Toolkit.
Inscrivez les détails de connexion du serveur cible (le serveur vers lequel vous migrez vos sites):
> cec register-server <target_server_name> -e http://<target_server>:<target_port> -u <target_username> -p <target_password> -t pod_ec
Pour migrer vos sites, procédez comme suit :
<site_name>
par le nom que vous souhaitez donner au site sur le serveur cible :
> cec migrate-site <site_name> --template <template_path_and_name> --destination <registered_target_server_name> --repository <repository_name>
Une fois que vous avez migré le site, il sera exécuté avec des appels REST de contenu version 1.1. Certains problèmes peuvent en découler. Vous devez les résoudre pour que le site soit exécuté correctement. Voici quelques informations pour vous aider à déterminer les actions à effectuer :
Une fois que votre site fonctionne correctement, vous devez le rendre compatible avec un site multilingue. Si vous deviez créer un site d'entreprise sur un serveur de calcul externe, il vous faudrait définir une langue par défaut et une stratégie de localisation. Votre site ayant été copié, il n'est pas multilingue. Vous devez donc le mettre à niveau vers un site multilingue pour vous assurer qu'il prend en charge cette future fonctionnalité.
Le tableau ci-après présente les différences entre les sites multilingues et les sites non multilingues.
Objet de site | Site multilingue | Site non multilingue |
---|---|---|
Eléments de contenu | La variante de langue de l'élément de contenu est affichée, pas l'élément déplacé vers la page. La langue peut être modifiée selon la langue demandée lors de l'affichage du site. | L'élément de contenu déplacé vers la page est toujours affiché. |
Présentations de contenu | Les présentations de contenu doivent prendre en charge les API version 1.1. Sinon, un message d'avertissement s'affichera à la place de l'élément de contenu. Cela est dû au fait que tous les appels d'API version 1.1 possèdent un élément "locale" qui a été ajouté et qui n'est pas pris en charge dans l'API version 1.0. | Les présentations de contenu peuvent prendre en charge la version 1.0 ou 1.1. Si la présentation de contenu prend uniquement en charge la version 1.0, ContentSDK ajoute une entrée "data" dans la réponse correspondant à l'entrée "fields". D'autres problèmes peuvent surgir, cette fonctionnalité ne doit donc pas être considérée comme prise en charge et la présentation de contenu doit être mise à niveau. |
Listes de contenu | Seuls les éléments de contenu disponibles dans la variante de langue demandée sont affichés. | Tous les éléments, peu importe la langue, sont affichés. L'utilisateur peut attacher les résultats à une langue donnée dans la liste de contenu, de sorte que deux listes de contenu sont affichées sur la page avec les résultats dans différentes langues. Cette option du panneau des paramètres permettant de choisir une langue n'est pas disponible pour les sites multilingues. |
defaultLocale | Les sites multilingues possèdent un environnement local de site par défaut. Par conséquent, toutes les requêtes de contenu renvoient uniquement les éléments de contenu de cet environnement local (ou non traduisibles). | Il n'existe aucun environnement local par défaut pour les sites non multilingues, la requête de contenu utilisée renvoie donc tous les éléments de contenu, peu importe la langue. |
Stratégie de localisation |
Définit la liste des langues disponibles sur le site. Le générateur de site contient une liste déroulante répertoriant ces langues. En outre, l'interface utilisateur de gestion contient une liste déroulante de langues vous permettant d'ouvrir/de prévisualiser le site dans la langue demandée. |
Comme il n'existe aucune stratégie de localisation, la liste déroulante permettant de modifier la langue est enlevée du générateur. L'interface utilisateur de gestion ne répertorie aucune langue, ni de langue "par défaut". Cette différence vous permet de reconnaître un site multilingue et un site non multilingue dans l'interface utilisateur de gestion. |
Traduction/Traduisible | Le menu contextuel de l'interface utilisateur de gestion dispose d'une option Traduire. Cette option vous permet de créer un travail de traduction pour traduire le site. |
Le menu contextuel de l'interface utilisateur de gestion dispose d'une option Traduisible. Un site non multilingue n'est effectivement pas traduisible. Vous devez donc le rendre traduisible (multilingue) pour pouvoir le traduire. C'est également ainsi que vous "mettez à niveau" un site non multilingue vers un site multilingue. Remarque : la mise à niveau est unidirectionnelle. Vous ne pouvez pas revenir à une version non traduisible. |
Pour transformer votre site en un site multilingue, vous devez effectuer les actions suivantes :
Ensuite, si vous avez du code de composant personnalisé qui effectue des appels REST de contenu, vous devez également le mettre à niveau pour qu'il puisse réaliser des appels version 1.1. Cette situation est peu probable car la plupart des appels de contenu sont effectués à partir des présentations de contenu.
Mise à niveau des présentations de contenu
Spécification des versions d'API REST de contenu prises en charge
Les présentations de contenu doivent indiquer la version d'API REST de contenu qu'elles prennent en charge. Il est ainsi garanti que l'appel REST de contenu approprié est effectué pour renvoyer les données de réponse attendues à la présentation.
Si vous n'indiquez aucune prise en charge de version, le système part du principe que la présentation de contenu prend uniquement en charge la version 1.0.
La console répertorie les présentations de contenu qui sont encore sous la version .0.
Pour permettre à votre présentation de contenu de prendre en charge d'autres versions, ajoutez la propriété "contentVersion" à votre objet de présentation de contenu.
Dans cet exemple, la présentation de contenu prend en charge toutes les versions de 1.0 incluse à 2.0 non incluse (remarque : la version 2.0 n'existe pas, mais des modifications majeures de version peuvent entraîner de nouveaux changements).
// Content Layout definition.ContentLayout.prototype = { // Specify the versions of the Content REST API that are supported by the this Content Layout. // The value for contentVersion follows Semantic Versioning syntax. // This allows applications that use the content layout to pass the data through in the expected format. contentVersion: ">=1.0.0 <2.0.0", // Main rendering function: // - Updates the data to handle any required additional requests and support both v1.0 and v1.1 Content REST APIs // - Expand the Mustache template with the updated data // - Appends the expanded template HTML to the parentObj DOM element render: function (parentObj) {
Gestion des modifications de réponse version 1.1
Vous devez au minimum gérer la modification de "data" en "fields" dans la réponse d'API REST de contenu. Pour ce faire, le plus simple est d'ajouter de nouveau la propriété "data" et de pointer vers la nouvelle propriété "fields".
render: function (parentObj) { ... if(!content.data) { content.data = content.fields; }
Le mieux est de modifier vos présentations de contenu pour qu'elles utilisent la valeur "fields" de la version 1.1. Cette opération implique de mettre à jour le code JavaScript et le code de modèle.
Pour prendre entièrement en charge la version 1.1, vous devez gérer les modifications d'API REST de contenu suivantes entre la version 1.0 et la version 1.1 :
Modification d'API REST de contenu | Version 1.1 | Version 1.0 |
---|---|---|
"fields" et "data" |
"items": [{ "type": "Starter-Blog-Author", "name": "Alex Read", "id": "COREB62DBAB5CEDA4915A9C9F6050E554F63", "fields": { "starter-blog-author_bio": "Alex's bio", "starter-blog-author_name": "Alex Read" } }, |
"items": [{ "type": "Starter-Blog-Author", "name": "Alex Read", "id": "COREB62DBAB5CEDA4915A9C9F6050E554F63", "data": { "starter-blog-author_bio": "Alex's bio", "starter-blog-author_name": "Alex Read" } }, |
Noms de propriété camelCase | "updatedDate" | "updateddate" |
Format de requête | /items?q=(type eq "Starter-Blog-Author") | /items?fields.type.equals="Starter-Blog-Author" |
Version d'API | /content/management/api/v1.1/items | /content/management/api/v1/items |
Requêtes propres à la langue | /content/management/api/v1.1/items?q=((type eq "Promo") and (language eq "en-US" or translatable eq "false")) |
Non prises en charge. Vous devez migrer tous les appels version 1 personnalisés pour inclure l'option de langue. Vous vous assurez ainsi que les résultats sont cohérents avec ceux renvoyés pour le site multilingue lorsqu'il est affiché dans une langue donnée. |
Mise à niveau de la chaîne de requête de contenu
Si du code personnalisé contient des appels d'API de contenu, vous devez valider tout le code personnalisé de votre site qui effectue des appels d'API REST de contenu.
Conversion d'un site non multilingue en un site multilingue
Une fois que vous avez converti votre site pour qu'il prenne entièrement en charge les API REST de contenu version 1.1, vous pouvez ajouter la prise en charge des langues en transformant le site en un site multilingue.
Si vous sélectionnez votre site dans l'interface utilisateur de gestion de site, l'option de menu de contenu Traduisible apparaît. Si vous sélectionnez cette option, une boîte de dialogue apparaît et vous invite à choisir une stratégie de localisation et une langue par défaut pour le site dans la liste des langues requises de la stratégie de localisation. Si aucune stratégie de localisation n'existe, vous ne pourrez pas accomplir cette étape. Vous devez d'abord accéder aux écrans d'administration de contenu et créer une stratégie de localisation contenant au moins une langue requise.
Une fois cette étape terminée, votre site affiche le contenu dans l'environnement local par défaut. Il est également possible de passer à d'autres environnements locaux indiqués dans la stratégie de localisation.
Vous devez vérifier que votre site affiche le contenu comme prévu dans l'environnement local par défaut.
Les ressources associées aux sites sont migrées en même temps que les sites, mais les ressources non associées doivent être migrées séparément.
Pour effectuer la migration, tenez compte des points suivants :
Pour migrer vos ressources, procédez comme suit :
Inscrivez les détails de connexion des serveurs source et cible.
Inscrivez le serveur source (le serveur à partir duquel vous migrez les ressources) :
> cec register-server <source_server_name> -e http://<source_server>:<source_port> -u <source_username> -p <source_password> -t pod_ic
Inscrivez le serveur cible (le serveur vers lequel vous migrez les ressources) :
> cec-install % cec register-server <target_server_name> -e http://<source_server>:<source_port> -u <target_username> -p <target_password> -t pod_ec
Pour migrer une collection de ressources, exécutez la commande suivante :
> cec migrate-content <source_collection_name> --server <source_server_name> --destination <target_server_name> --repository <target_repository_name> --collection <target_collection_name> --channel <target_channel_name>
Cette commande crée les ressources sur le serveur cible dans le référentiel indiqué, et les associe à la collection et au canal. Le cas échéant, la collection et le canal sont créés automatiquement. La langue par défaut de toutes les ressources migrées est la langue par défaut définie dans le référentiel indiqué.