Als u Oracle Content Management instances uitvoert op oude Cloud Infrastructure met een onbemeterd abonnement, wordt aanbevolen om deze instances te migreren naar de nieuwe native Oracle Cloud Infrastructure (OCI) omgeving, OCI Gen 2 (dat wil zeggen dat de service-instances worden beheerd met Infrastructure Console). Dit zorgt ervoor dat u in de toekomst profiteert van de voordelen en verbeteringen van het cloudplatform van Oracle.
Voordat u het migratieproces start, moet u enkele stappen uitvoeren en de migratie samen met Oracle Support plannen.
In deze tabel wordt de toewijzing van Oracle Content Management autorisatiegroepen voor OCI applicatierollen beschreven.
| Oracle Content Management autorisatiegroep | OCI-applicatierol |
|---|---|
| DocumentsServiceUser | CECStandardUser |
| DocumentsServiceAdmin | CECServiceAdministrator |
| SitesServiceVisitor | CECSitesVisitor |
| SitesServiceAdmin | CECSitesAdministrator |
| ContentAdministratorRole | CECContentAdministrator |
| CECSStandardUser | CECStandardUser |
| CECSEnterpriseUser | CECEnterpriseUser |
Opmerking:
Als het IDCS-doeldomein al een gebruiker met dezelfde gebruikersnaam bevat, worden aan de gebruiker de OCI applicatierollen toegewezen die corresponderen met de Oracle Content Management autorisatiegroepen van de gebruiker.Wanneer u gereed bent voor migratie, moet u een migratieaanvraag versturen om het proces op gang te brengen:
Nadat Oracle Support uw serviceaanvraag voor migratie heeft ontvangen, plannen we uw migratie in op basis van de datum die u heeft aangevraagd. De serviceaanvraag wordt bijgewerkt met de datum en tijd waarop uw migratie zal beginnen.
De serviceaanvraag wordt bijgewerkt om de voortgang van de migratie te tonen. De gegevensmigratie wordt op de achtergrond bijgewerkt, er is geen actie vereist van uw kant anders dan de updates van de serviceaanvraag bij te houden en de migratie te valideren zodra die gereed is.
Dit is wat er tijdens de migratie gebeurt:
Belangrijk:
Op dit punt mag u geen wijzigingen maken in uw oude (bron)instance. Alle wijzigingen die zijn gemaakt nadat de migratie is gestart, worden niet naar uw nieuw instance gemigreerd.Opmerking:
De oude instance blijft behouden zodat u deze kunt raadplegen voor validatiedoeleinden. U moet ook alle sites die gebruikmaken van activa migreren en alle overige activa migreren die van de migratie waren uitgesloten.Als uw oude instance met andere services of applicaties was geïntegreerd of er mee communiceerde, hetzij rechtstreeks hetzij via REST-API-aanroepen, dan moet u mogelijk post-migratietaken uitvoeren.
De volgende items zijn van toepassing op alle services:
De oude URL's maakten gebruik van het volgende patroon:
https://<servicenaam>-<accountnaam>.<regio>.oraclecloud.com/documents
De nieuwe URL's maken gebruik van het volgende patroon:
https://<servicenaam>-<accountnaam>.<servicetype>.ocp.oraclecloud.com/documents
| Integratie | Wat u moet doen na migratie |
|---|---|
| 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 |
|
| REST-API-aanroepen |
|
| Gebruik client SDK/CL |
|
| Connectoren |
|
Opmerking:
Alle bladwijzers in uw inhoud op uw oude instance werken niet meer omdat de URL van uw nieuwe instance is gewijzigd.Sites die geen gebruikmaken van activa worden automatisch gemigreerd, maar voor sites die wel gebruikmaken van activa moeten enkele aanvullende stappen worden uitgevoerd. Anders werken ze niet correct in uw nieuwe Oracle Content Management instance.
De opdracht "cec migrate-site" is nieuw, dus u moet de OCE Toolkit installeren vanuit de Git-repository voor webclients, ook als u deze al eerder hebt gedownload en geïnstalleerd.
Volg de aanwijzingen op de pagina met de toolkit voor sites om de OCE Toolkit te downloaden en te installeren.
Registreer de verbindingsgegevens voor de doelserver (de server waarnaar u sites migreert):
> cec register-server <target_server_name>
-e http://<target_server>:<target_port>
-u <target_username> -p <target_password>
-t pod_ec
Voer de volgende stappen uit om uw sites te migreren:
<site_name> door de gewenste naam voor de site op de doelserver:
> cec migrate-site <site_name> --template <template_path_and_name> --destination <registered_target_server_name> --repository <repository_name>
Na de migratie van uw site wordt deze uitgevoerd met Content REST v1.1-aanroepen. Dit kan enkele problemen veroorzaken die moeten worden opgelost voordat de site correct functioneert. Bekijk de volgende punten om te bepalen wat u moet doen:
Als uw site eenmaal correct functioneert, moet u deze MLS-compliant maken. Als u een bedrijfssite op een External Compute server maakt, is een standaardtaal en een lokalisatiepolicy vereist. Na het kopiëren van uw site is het nog geen MLS-site, dus u moet de site upgraden naar een MLS-site zodat toekomstige functionaliteit wordt ondersteund.
In de volgende tabel ziet u de verschillen tussen MLS-sites en niet-MLS-sites.
| Siteobject | MLS-site | Niet-MLS-site |
|---|---|---|
| Inhouditems | De taalvariant van het inhouditem wordt weergegeven, niet het inhouditem dat op de pagina is neergezet. De taal kan worden gewijzigd, afhankelijk van de gekozen taal waarin de site wordt weergegeven. | Het inhouditem dat op de pagina is neergezet, wordt altijd weergegeven. |
| Inhoudlay-outs | Inhoudlay-outs moeten v1.1 API's ondersteunen. Anders wordt er een waarschuwing weergegeven in plaats van het inhouditem. Dit komt doordat aan alle aanroepen voor v1.1 API's een "locale" wordt toegevoegd die niet wordt ondersteund in de v1.0 API. | Inhoudlay-outs kunnen v1.0 of v1.1 zijn. Als de inhoudlay-out alleen v1.0 ondersteunt, wordt door ContentSDK de ingang "data" in de respons toegevoegd voor de corresponderende ingang "fields". Er kunnen zich nog andere problemen voordoen, dus beschouw dit niet als ondersteunde functie voor het upgraden van de inhoudlay-out. |
| Inhoudlijsten | Alleen inhouditems die beschikbaar zijn in de aangevraagde taalvariant worden weergegeven. | Alle inhouditems worden weergegeven, ongeacht de taal. De gebruiker heeft de mogelijkheid in de inhoudlijst om de resultaten te koppelen aan een specifieke taal. Zo kunt u twee inhoudlijsten op de pagina hebben waarin resultaten worden getoond in verschillende talen. Deze taalkeuzeoptie in het instellingenpaneel is niet beschikbaar voor MLS-sites. |
| defaultLocale | MLS-sites hebben een standaardlandinstelling. Dit betekent dat alle inhoudquery's alleen inhouditems in die landinstelling (of niet-vertaalbare inhouditems) retourneren. | Een niet-MLS-site heeft geen standaardlandinstelling, dus de gebruikte inhoudquery retourneert alle inhouditems, ongeacht de taal van het inhouditem. |
| Lokalisatiepolicy |
Hiermee wordt de lijst met beschikbare talen voor de site gedefinieerd. Er is een dropdownlijst hiervan in de builder. Ook in de beheerinterface is er een dropdownlijst van talen zodat u de site kunt openen/bekijken in de aangevraagde taal. |
Omdat er geen lokalisatiepolicy is, is de dropdownlijst voor het wisselen van de taal verwijderd uit de builder. In de beheerinterface wordt geen taalkeuzelijst weergegeven en ook geen standaardtaal. Zo herkent u niet-MLS-sites versus MLS-sites in de beheerinterface. |
| Vertaling/Vertaalbaar | Het contextmenu in de beheerinterface bevat de optie "Vertalen". Hiermee kunt u een vertaaltaak maken om de site te vertalen. |
Het contextmenu in de beheerinterface bevat de optie "Vertaalbaar". Een niet-MLS-site is feitelijk niet-vertaalbaar, dus u moet deze eerst vertaalbaar maken (er een MLS-site van maken) voordat u de site kunt vertalen. Dit is ook hoe u een "upgrade" op een site uitvoert van niet-MLS naar MLS. Opmerking: dit proces is onomkeerbaar. U kunt geen downgrade uitvoeren van vertaalbaar naar niet-vertaalbaar. |
Voordat u een MLS-site van uw site kunt maken, moet u het volgende doen:
Als u code met aangepaste componenten hebt waarmee Content REST-aanroepen worden uitgevoerd, moet u deze ook upgraden naar Content REST v1.1-aanroepen. Dit is niet gebruikelijk omdat de meeste Content-aanroepen worden uitgevoerd vanuit inhoudlay-outs.
Inhoudlay-outs upgraden
Ondersteunde Content REST-API-versies opgeven
In inhoudlay-outs moet worden opgegeven welke versie van de Content REST-API ze ondersteunen. Dit zorgt ervoor dat de juiste Content REST-aanroep wordt uitgevoerd om de verwachte responsgegevens te retourneren naar de lay-out.
Als u geen versieondersteuning opgeeft, wordt aangenomen dat de inhoudlay-out alleen v1.0 ondersteunt.
In de console worden de inhoudlay-outs weergegeven die nog v1.0 hebben.
Als u in uw inhoudlay-out ondersteuning voor andere versies mogelijk wilt maken, voegt u de eigenschap "contentVersion" toe aan uw inhoudlay-outobject.
In dit voorbeeld wordt ondersteuning voor alle versies tussen v1.0 en 2.0 opgegeven (opmerking: versie 2.0 bestaat niet, maar baanbrekende wijzigingen kunnen ook leiden tot grote versiewijzigingen).
// 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)
{
Afhandeling van v1.1 responswijzigingen
Het minste wat u moet doen is de Content REST-API responswijziging van "data" in "fields" af te handelen. De eenvoudigste manier om dit te doen, is de eigenschap "data" weer toe te voegen en te verwijzen naar de nieuwe eigenschap "fields".
render: function (parentObj)
{ ... if(!content.data) { content.data =
content.fields; }
Een betere optie is uw inhoudlay-outs zo te wijzigen dat de v1.1 waarde voor "fields" wordt gebruikt. Hiervoor moet u zowel uw JavaScipt-code als sjablooncode bijwerken.
Voor volledige ondersteuning van v1.1 moet u de volgende Content REST-API-wijzigingen tussen v1.0 en v1.1 afhandelen:
| Content REST-API-wijziging | v1.1 | v1.0 |
|---|---|---|
| "fields" versus "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" } }, |
| eigenschapsnamen in KameelKapitalen | "updatedDate" | "updateddate" |
| query-indeling | /items?q=(type eq "Starter-Blog-Author") | /items?fields.type.equals="Starter-Blog-Author" |
| API-versie | /content/management/api/v1.1/items | /content/management/api/v1/items |
| taalspecifieke query's | /content/management/api/v1.1/items?q=((type eq "Promo") and (language eq "en-US" or translatable eq "false")) |
Niet ondersteund. U moet alle aangepaste v1-aanroepen migreren om de optie "language" op te nemen. Dit zorgt ervoor dat de resultaten consistent zijn met de resultaten die voor de MLS-site worden gertourneerd wanneer deze wordt bekeken in een specifieke taal. |
Inhoudquerystring upgraden
U wilt wellicht Content-API-aanroepen uitvoeren in alle aangepaste code, dus u moet alle aangepaste code valideren die op uw site wordt gebruikt voor het uitvoeren van Content REST-API-aanroepen.
Een niet-MLS-site converteren naar een MLS-site
Nadat u uw site hebt geconverteerd voor volledige ondersteuning van v1.1 Content REST-API's, kunt u ondersteuning voor talen toevoegen door uw site te converteren naar een MLS-site.
Als u uw site selecteert in de beheerinterface, bevat het inhoudmenu de optie "Vertaalbaar". Als u deze optie selecteert, wordt een dialoogvenster weergegeven waarin u wordt gevraagd een lokalisatiepolicy te kiezen, en een standaardtaal voor de site in de lijst met vereiste talen voor de lokalisatiepolicy. Als er geen lokalisatiepolicy's zijn, kunt u deze stap niet voltooien en moet u eerst naar de inhoudbeheerschermen gaan en een lokalisatiepolicy met ten minste één vereiste taal maken.
Na voltooiing van deze stap wordt uw site weergegeven in de standaardlandinstelling. Bovendien kunt u overschakelen naar de andere landinstellingen die u in de lokalisatiepolicy hebt opgegeven.
U dient te valideren of uw site wordt weergegeven in de standaardlandinstelling zoals u verwacht.
Activa die zijn gekoppeld aan sites worden gemigreerd wanneer u de sites migreert, maar alle activa die niet aan sites zijn gekoppeld moeten afzonderlijk worden gemigreerd.
Voordat u met migreren begint, moet u rekening houden met de volgende punten:
Voer de volgende stappen uit om uw activa te migreren:
Registreer de verbindingsgegevens voor de bronserver en de doelserver.
Registreer de bronserver (de server waarvan u activa migreert):
> cec register-server <source_server_name>
-e http://<source_server>:<source_port>
-u <source_username> -p <source_password>
-t pod_ic
Registreer de doelserver (de server waarnaar u activa migreert):
> cec-install % cec register-server <target_server_name>
-e http://<source_server>:<source_port>
-u <target_username> -p <target_password>
-t pod_ec
U migreert een verzameling activa met de volgende opdracht:
> 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>
De activa worden gemaakt op de doelserver in de opgegeven repository en aan de verzameling en het kanaal gekoppeld. Zo nodig worden de verzameling en het kanaal automatisch gemaakt. De standaardtaal voor alle gemigreerde activa wordt de standaardtaal die is ingesteld in de opgegeven repository.