Removing GSF after upgrade to 11.1.1.8

Question

Hi,
We are currently running WebCenter Sites 11.1.1.6 with GSF in our environments. We wish to upgrade to 11.1.1.8.
WCS 11.1.1.8.0 includes vanity URL support. So we want to remove the GSF during this upgrade.
I have following questions -
·         What are the differences between the GST framework and the new web-friendly URL attribute?
·         What are some of the things we need to consider (high level steps) to get this done to eliminate the GST references in our environment?
·         Are there any known risks/issues while removing GSF?
Thanks a ton!

Answer 1

Hi,
PFB answers to your question
GSF has a lot of features, one of them is Vanity URL support. In our implementation, we removed GSF Vanity URL and used OOTB Vanity URL Support and went live 2 months back.
Q1. Differences between GST-Framework and New Friendly URL attribute
Pros of New OOTB Friendly URL
1. GST Framework uses a URLAssembler to implement Friendly URLs, with the new Version it is Productized and does not require any URL Assemblers
2. GST Stores all URLs of the Site in GSTURLRegistry Table, which gets populated using a AssetListener
  OOTB VanityURL does nto need any of these listeners and gets populated into WebReferences Table
3. GST uses the "path" field metadata tab to populate User Defined Vanity URL
   OOTB Vanity URL provides a separate tab called URL on the screen, which allows you user to define a Custom Vanity URL
4. GST limits the number of URLs for an Asset to be 1
   OOTB Vanity URL allows you to create multiple URL for an Asset with different templates
5. GST does not support 301 and 302 redirects
   OOTB Vanity URL supports 301 and 302 redirects
6. Automation of URL generation was not supported by GSF
   OOTB Vanity URL supports Auto Generation of Vanity URLs with predefined functions thta can be applied to asset attributes
Cons of New OOTB Friendly URL
1. GSF has a Custom Servlet Filter that allows users to generate a 404 page from a CSElement which could use an Asset for authorign the page and can be handled by Publishers (This sets a 404 response )
   OOTB Vanity URL returns a blank 404 Page, it does nto sendError and just setsSatusCode to 404, thereby Custom Servlet Filters may be needed to support a Custom 404 Page, but not too difficult to handle
2. GSF honours Asset Start Date and End Date and will throw a 404 until the desired date and time
   OOTB Vanity URL does not support startdate and end date
Q2 What are some of the things we need to consider (high level steps) to get this done to eliminate the GST references in our environment?
1. Note we continued to use Data Access of GSF even after Upgrade, so we did not remove the JAR file from Server, btu if you are not using gsf tld or API then remove the following JAR
( Usually Upgrade would have taken care of this, but good to check and add this JAR if you continue to use Asset API)
Remove gst-*jar from WEB-INF/lib/
2. Delete GST entries from AssetListener_reg table & flush the table
There are three rows in the assetlistener_reg table that need to be deleted.  Use the following command to delete all three.
Delete from assetlistener_reg where listener like 'com.fatwire.gst.foundation%';
Do the following steps to clear the result set cache for the assetlistener_reg table in WCS:
Log into the WCS Admin application
Click the Admin tab
Expand the "System Tools -> Cache Management -> Resultset Cache -> Summary" tree section
Check the checkbox next to the entry "wcs_dbAssetListener_reg" (Note this could change based on schema and db naming conventions but AssetListener_reg table cache needs to be flushed )
Click the "Clear" button near the top of the page.
3. Update futuretense_xcel.ini xcelerate.pageref ( Usually Upgrade would have taken care of this, but good to check )
Previous value: xcelerate.pageref=com.fatwire.gst.foundation.url.WraPageReference
New Value: xcelerate.pageref=com.openmarket.xcelerate.publish.PageRef
4. Remove any References to GSF URL Assembler in ServletRequest.properties ( Usually Upgrade would have taken care of this, but good to check )
5. Change Webserver Rewrites from GSF to Vanity URL
Refer to docs below for full steps
(http://docs.oracle.com/cd/E29542_01/doc.1111/e29636/config_vanity_url.htm#i1093062)
Decide your strategy for Vanity URL and use below Config for Rewrites
Webserver Rewrite
To use Vanity URL with the Web Server a URL, rewrite rule has to be set in the Web Server. The rewrite rule should split the incoming URL into two parts lookuppage and lookuphost. These two parts should be sent to Web Center Sites as shown below
/<contextpath/Sites? lookuppage=<lookuppage>&lookuphost=<lookuphost>
This can be done in one of the two following ways
1) In this case lookuphost matches the Root URL defined in the Web Root. Lookuppage is the remaining part of the incoming URL.
Examples:
(a) Root URL – www.sitedomain.com
Incoming URL - http://www.sitedomain.com/us/custom/products.html
Rewritten URL - “/sites/Sites?lookuppage=/us/custom/products.html&lookuphost=http://www.sitedomain.com”.
mod_rewrite - “RewriteRule ^(.*)$ /sites/Sites?lookuppage=($1)&lookuphost=http://www.sitedomain.com [L]”
(b) Root URL – http://www.sitedomain.com/us/
Incoming URL - http://www.sitedomain.com/us/custom/products.html
Rewritten URL - “/sites/Sites?lookuppage=/custom/products.html&lookuphost=http://www.sitedomain.com/us/”.
mod_rewrite - “RewriteRule ^us(.*)$ /sites/Sites?lookuppage=($1)&lookuphost=http://www.sitedomain.com/us/ [L]”
2) This is simplest of the two. The rewrite rule does not change based on the WebRoot definition. In this case lookuphost is just the domain part of the Root URL defined in the WebRoot. Lookuppage is the remaining part of the incoming URL.
Examples:
(a) Root URL – http://www.sitedomain.com/ . Incoming URL - http://www.sitedomain.com/us/custom/products.html
(b) Root URL – http://www.sitedomain.com/us/ . Incoming URL - http://www.sitedomain.com/us/custom/products.html
For both the scenarios the Rewritten URL and mod-rewrite rule remains the same.
Rewritten URL - “/sites/Sites?lookuppage=/us/custom/products.html&lookuphost=http://www.sitedomain.com/”.
mod_rewrite - “RewriteRule ^(.*)$ /sites/Sites?lookuppage=($1)&lookuphost=http://www.sitedomain.com/ [L]”
Recommendation
We always have our root URL to be  just the domain,as it will be scalable when we start serving multi lingual pages within Sites.
http://www.sitedomain.com
http://m.sitedomain.com
Q3. Any risk with the change
a. We did not hit anything major apart from 404 support
b. You also need to take care of migrating the URL from existing GSFURLRegistry to WebReferences and flush the cache and restart the servers.
Analysing table schema for GSFURLRegistry and WebReferences and map them for each column
other option is setup a urlpattern
${path!=null?path.substring(1):""} and edit and save all assets that have an entry in gSTURLRegistry. This will increase a version on the asset and may err out if an asset is checkedout by publisher.
Post doing EditSave, you need to run the below query for every assettype you did the above operation and flsuh table cache and restart server once done
update webreferences set patternid=0 where patternid!=0 and assettype='<assetype>'
Reach out to me on this thread if you run into issues
Cheers!!