Home – Blog – Best Practices: How to install both GSF and CSDT in WebCenter Sites
November 14, 2012 —
So you’re building a new website in WebCenter Sites and you’ve decided to use CSDT (Content Server Developer Tools) and GSF (GST Site Foundation) to help make the development process as efficient as possible. The steps for installing GSF are quite simple. Copy a few files, click a few links, and you’re done. Setting up CSDT is easy too — once you get the hang of the differences between importing and exporting and what direction those commands sync your assets — always think of it relative your WebCenter Sites installation: You import to WebCenter Sites, and export from WebCenter Sites. But I digress. What about setting up GSF and CSDT in the same environment? Can I install them in any order I want?
Well, you might have guessed that there are three possible ways to do this:
- Install GSF, then setup CSDT
- Setup CSDT, then install GSF
- A mix of the two (the correct way)
And for the sake of clarity, we’re assuming that setting up CSDT also involves downloading an existing CSDT workspace from a VCS and importing it to your local JSK. Before I lose your attention, I should tell you that one of these options is a lot easier than the others (hint: it’s the third one). Let’s take a look at what happens in all three scenarios.
OPTION 1: INSTALL GSF, THEN SETUP CSDT
In this method, you’ll make through the GSF installation without any problems, but you’ll run into issues pretty quickly after you download the CSDT workspace from your VCS and you’re trying to sync the content to WebCenter Sites. The CSDT sync will fail as soon as it tries to import one of the GST @ASSET_TYPE assets. The error message in your error log will look something like this:
Importing DSKEY @ASSET_TYPE-7d136fbb-80e3-4832-85ee-1c44f2d40b0b (batch 1352902950106)
Import Error: asset type conflict: GSTVirtualWebroot already exists with different fw_uid, aborting import.
Now don’t worry. You can fix this by deleting the entire GST flex family (i.e. the GSTAttribute asset type and everything underneath it in the Flex Family Maker), then re-syncing everything from your CSDT workspace. In the end, this will still get the GSF and CSDT setup, but it’s not the cleanest solution.
OPTION 2: SETUP CSDT, THEN INSTALL GSF
In this method, both the CSDT setup and the GSF installation will appear to run just fine. No error messages in the logs or anything. But if you’re using GSF’s vanity URL or tagging support, they’re not going to work. Both of these features rely on asset event listeners to populate custom database tables (the tables are ‘GSTUrlRegistry’ and ‘GSTTagRegistry’ if you’re curious). Since the GSF was installed after you imported all your content from the CSDT workspace, the asset event listeners were not in place when you imported your content into WebCenter Sites and the database tables used by GSF’s vanity URLs and tagging support are going to be empty. This means your vanity URLs will return HTTP 404 errors, and it will appear as if nothing is tagged in your site.
The GSF Dashboard (the WEM app) has a utility to rebuild the URL registry, but it doesn’t have anything for rebuilding the tagging registry. Now you can probably fix the tags too — by loading and re-saving every asset in your site — but who wants to do this sort of data cleanup? It would be much better if you could setup GSF and CSDT correctly in the first place and avoid data cleanup altogether. Which brings us to option 3.
OPTION 3: A MIX OF THE TWO (THE CORRECT WAY)
In this method, you setup both the GSF and CSDT at the same time. More specifically, I mean:
- Setup Eclipse and point the WebCenter Sites Perspective to your local JSK. Download your existing CSDT workspace from your VCS, but don’t import anything into WebCenter Sites yet.
- Import only the following into WebCenter Sites:
- all @SITE assets — including the GST site and your site(s)
- all @ASSET_TYPE assets — including the GST asset types and any that you have created
- all the GSTAttribute and GSTDefinition assets
Importing these things now (before the GSF installation) will ensure we won’t run into the ‘fw_uid’ error from Option 1.
- Install the GSF. You know — copy some files to your app server, import some things using CatalogMover, then run the GSF installer in the GSF WEM app. Normally, when installing GSF into a brand new environment, the GSF would create the GST flex family, the GST Attributes, and GST Definitions for you. But in this case, we already did that when we ran part of the CSDT import earlier in step #2. That’s no problem because the GSF installer will automatically see that these things already exist in your environment and it will proceed with the rest of the installation.
- Import everything else from your CSDT workspace into WebCenter Sites. Now when you import the rest of your CSDT workspace, the GSF vanity URL and tagging support features will work as they should because your asset types have been imported properly and the GSF was already installed.
- All done. You’re ready to build the rest of your website.
So, while none of these installation methods will result in anything catastrophic or unrecoverable, there is a clean, hassle-free way to setup GSF and CSDT in your site. Now you can spend less time on trouble-shooting installation issues and data cleanup, and more time building your website. Happy coding!