As part of migrating an XM project to XM Cloud, I came across one interesting scenario/pattern and later came to know from Rey Rahadian that this code is actually part of XMCloud starter kit project. I felt that this deserves a separate blog post. So, here I'm with a unique XM Cloud blog post - there might be scenarios when you would want to keep your item GUID secretive across machines or postpone its generation until the final stage of up script. Or, in other words, you don't want the actual item to be serialized to the file system. Here is the up script line I'm talking about:
In the above scenario, after all serialized items are pushed to the Sitecore local instance, the api key is picked from .env file (can be dynamically generated as part of init process) and sent as param to a separate
import-templates.ps1 script from up script.
An interesting part of this process is - a modules folder is generated from existing \docker\build\cm\templates\modules_template folder with the guid flowing in from .env file and template.yml fetched from \docker\build\cm\templates\modules_template folder. Now, the dynamically generated template.yml file (under a sub-folder in \docker\build\cm\templates\modules parent folder) is pushed as a Sitecore item by a dynamically generated ApiKey.module.json file. Here is a diagrammatic representation of the process:
\docker\build\cm\templates\modules_template folder - template.yml: with the Sitecore_API_Key placeholder for dynamic GUID and associated key name:
Associated ApiKey.module.json template that assists in generation of actual ApiKey.module.json with actual key name to be pushed:
Sample .env file with variable for api key:
Auto-generated ApiKey.module.json during up.ps1 execution:
End-result:
Actual Scenario:
Wait its not over yet, here is the actual scenario that made me notice this pattern. If you are migrating from Unicorn config files to CLI module json files, it is pretty well known that Unicorn config files have the serialization data store named by default as serialization while the CLI data store defaults to items in sitecore.json file under base path (this is the one that gets copied by Import-templates.ps1).
Next, if you copy-over the up.ps1 and \docker\build\cm\templates as-is from
XMCloud starter kit project, the template.yml in the \docker\build\cm\templates\modules_template folder will reside under items\api-key folder. Going further as -is, if you execute the up.ps1 as-is, the template.yml file will be generated under \docker\build\cm\templates\modules\items\api-key (yes, based on what is in \docker\build\cm\templates\modules_template folder).
Now, remember that the sitecore.json had its defaultModuleRelativeSerializationPath (our serialization data store path) changed to serialization, since we are trying to follow the same pattern as Unicorn, then your up script will fail with the following error:
Configured source item path /sitecore/system/Settings/Services/ API Keys/xmcloudpreview did not exist in serialized items (1 subtrees datastore).
The resolution is, change the \docker\build\cm\templates\modules_template' sub-folder to reflect the corresponding serialization data store name or whatever name you decide for defaultModuleRelativeSerializationPath in base sitecore.json. In my case (as per this post), serialization will be the sub-folder name instead of items and then try up.ps1 for ser push to succeed since the new yml will now be generated in the location expected by CLI/sitecore.json.
I think there is scope here for a
XMCloud starter kit project PR in the form of updating the import-templates.ps1 script to look at the sitecore.json file and find the defaultModuleRelativeSerializationPath on-the-fly and then smartly generate the template.yml under the new dynamic sub-folder within modules folder instead of the path in the modules_template folder since a template should be used as a template irrespective of folder or file!
Comments
Post a Comment