We have observed that there is some synchronization tasks run after we import portalsite library from one environment to another environment. It seems that this synchronization tasks run xmlaccess to create a pages in portal that are there in portalsite library.
Sometimes this synchronization fails due to missing portlet definition or missing theme or missing some other dependency. Is there any way this synchronization tasks can be executed manually without re-importing the portalsite library?
Can you tell us which synchronization task is failing?
What are you trying to accomplish -- i.e. is this a new environment for test?
Is this a virtual portal?
Another consideration is using Syndication: https://opensource.hcltechsw.com/digital-experience/CF221/deployment/manage/staging_to_production/updates_with_syndication/dep_up_syn/
We are having hundreds of pages that needs to be setup on new environment and hence exporting portalsite library from source environment and import it to destination environment.
In case the xmlaccess script executed as part of the syndication (to sync Portal Site to release db) fails the page should show as failing syndication in the syndicator and after fixing the OID mismatch you should be able to retry all failed items.
That being said the create-page-nodes config task tries to synch pages in both directions but should ideally only be executed after a backup and if indicated by support.
According to this documentation https://help.hcl-software.com/digital-experience/8.5/wcm/wcm_config_mngpages_enable.html, create-page-nodes task populate portal site library with portal pages and it seems to be running in single direction only.
Can I get information which XMLAccess script gets executed once portalsite library import is completed? In the logs we see it gets 100% import and after that it took almost 3 to 4 hours for ConfigEngine to respond build success. It means there's something still going on after importing the files.
The task can also be used when portal pages and managed pages artifacts in Web Content Manager are not synchronized. In this case, the task attempts to resynchronize the portal artifacts and web content artifacts, giving precedence to the portal artifacts. While it gives precedence it looks at both. But as mentioned would suggest to check in a support case if needed.
The xmlaccess script is stored with each JCR node representing the page in the ibmcontentwcm:portalPageXML property of the node. So there is no overall script - there is one per page.