Sometimes when migrating Portal Registry objects I find that they do not show up in the Navigator, or even Structure and Content, until I clear cache, run VERSION, or even make a nominal change to the Portal Registry. We talked about this on the podcast in episode #303. I took Kyle’s idea of adding a sibling record in Structure and Content and traced what SQL was changing when saving the sibling record. There were
INSERT statements for the new CREF, but there are also some important VERSION updates.
- Update overall VERSION to track the new changes
- Update the VERSION specifically for the Portal Registry object types
- Update the VERSION for the parent Portal Registry folder (in my case, the Root folder)
Below is a script I use with Phire; we execute this script after the object migration to make sure our new CREFs are visible.
-- Update overall VERSION for SYS and PRSM types update PSVERSION set VERSION = VERSION + 1 where OBJECTTYPENAME in ('SYS','PRSM'); -- Update VERSION for Portal Registry objects UPDATE PSLOCK SET VERSION = VERSION + 1 WHERE OBJECTTYPENAME = 'PRDM'; UPDATE PSLOCK SET VERSION = VERSION + 1 WHERE OBJECTTYPENAME = 'PRSM'; -- Update CREF Parent - Change PORTAL_OBJNAME as needed UPDATE PSPRSMDEFN SET VERSION = (select VERSION from PSLOCK where OBJECTTYPENAME = 'PRSM'), LASTUPDDTTM = TO_TIMESTAMP(sysdate,'YYYY-MM-DD-HH24.MI.SS.FF') WHERE PORTAL_NAME = 'EMPLOYEE' AND PORTAL_REFTYPE = 'F' AND PORTAL_OBJNAME = 'PORTAL_ROOT_OBJECT'; commit;
Thanks for Andy Dorfman for catching a change in my original SQL. The first statement should include both the
5 thoughts on “Portal Registry Migration Fix”
Golden rule. When migrating crefs always migrate the parent folder even if there are no changes to the folder. This will cref force this
That’s a great suggestion Graham!
Continuing with Graham’s advice… When you use the component registration wizard, it usually adds the parent folder to the project. The problem is when you do your compare/report, it sets the parent folder to same/same, no copy. Check the box to copy anyway, and that will increment the version number, and eliminate the cache issue.
The portal registry loads top down. If you insert a child after the parent is in the cache, the parent won’t reload. But updating the parent version number (through migration) forces it to reload its children. When inserting new top-level folders, migrate PORTAL_ROOT_OBJECT.
Would Data Migration Workbench take care of those 3 steps? My experience with migrating CREFs or any other portal object has been without issues using DMW. Granted, you have to run the Validate/Compare Report and see its results details at the record level. There, at the matrix table resutls, you would see the next version number that it would take place. The only thing is that you have the use the 2 delivered Data Sets for the API to take care of that. Costume DS wont work.