Webpublisher slowdown traced to UNC link fields

I've been working with a set of client textbases for a little while, and have been flummoxed by Inmagic Webpublisher taking up to 30 seconds to return a puny 50 record result set. There are a lot of secondary link fields in these textbases, and I had a gut feeling they were to blame. Somehow.

I assumed the link fields were pointing to local dev copies of the secondary textbases. I was wrong. I just discovered that the link fields were trying to reach out via UNC path to a servername in my client's network environment. Ah.

\\someServerName\path\textbase.tba

Almost every query except the cached ones were attempting to resolve this network path, thus accounting for the incredible amount of time spent churning. I had even noticed that refreshing the page after a timeout got the full query results in a fraction of a second, but didn't connect the dots. (I.e. query results were completed in every case, so the response wasn't hung up on the query process per se.)

Sigh. The hardest thing to do when troubleshooting is to uncover one's own assumptions.

Could Google index a Webpublisher database?

I hear people ask this question a lot: "Can Google index my Inmagic Webpublisher database?" And so far, the answer has been a disappointing "nope". Database records are only reachable via complicated URLs with long query strings, and search engine policy is to ignore such URLs.

But I had a thought today while listening to a .NET Rocks! podcast about the recent ASP.NET implementation of the MVC (model-view-controller) pattern, and how one of its big strengths is the ability to work with predictable and logical URLS that don't have to correspond to a file on disk, negating the need for clever URL rewriting. Jeff Palermo, the expert interviewee on the subject, cited an example URL an online retailer might use to make its widget products indexable by search engines:

/widgetCategory/widget1/red

And I thought, why not do this for Webpublisher? Not put the MVC pattern into practice necessarily, but use URLs like that to produce Webpublisher query results. With clever URL rewriting. (I.e. handle the URL behind the scenes server-side, not merely *redirect*.)

For example, /catalog/title/the_golden_compass could search for "Title = 'The Golden Compass' in the Catalog database." The path would contain the logic required to construct the query. More examples:

/catalog/author/smith 

/catalog/recordid/123

/catalog/datemodified/2008-01-01

One would then need to produce some kind of site map that gave Google the links to follow.

I bet this would work. I'll try it in the next few weeks and report back.

Running Inmagic Genie without Content Server

Why not hack Genie this holiday season? Chestnuts roasting on an open fire, Jack Frost nipping at your nose, Genie excised from Content Server and forced to run on DB/Text Webpublisher... Ho ho ho!

This was my first run at getting Genie to work with DB/Text Webpublisher instead of CS Webpublisher. There is definitely room for improvement, but this was the proof of concept.

There are just two tweaks, neither of which involve access to Genie's source code: 1) a redirect from /ics-wpd/exec/icswppro.dll to /dbtw-wpd/exec/dbtwpub.dll, and 2) alteration of Genie SOAP file locations in web.config. Oh, and of course, one must recreate all the Genie textbases in DB/Textworks. Alright, three tweaks.

httpRedirect

I did this on a Vista Ultimate machine, so the specifics are valid for IIS 7 only, but the concept is still applicable to IIS 5 or 6.

Internally, Genie has the CS Webpublisher ISAPI location hard-coded all over the place. Since it is not possible to override these within the Genie application, we have to do it externally, which is where HTTP redirect comes in.  Thus Genie merrily continues to make requests to CS Webpublisher, but we re-route all those requests to DB/Text Webpublisher.

In applicationHost.config, I enabled httpRedirect with a response status of "Temporary" (we'll see why in a minute) and added a wildcard to route CS Webpublisher requests to DB/Text Webpublisher:

<httpRedirect enabled="true" exactDestination="true" httpResponseStatus="Temporary">

    <add wildcard="/ics-wpd/exec/icswppro.dll" destination="/dbtw-wpd/exec/dbtwpub.dll$Q" />

</httpRedirect>

The $Q placeholder sends all querystring variables to the new URL, which covers GET requests. The response status "Temporary" (HTTP status code 307) is the only response status which sends POST requests on to the new URL. Permanent (301) and Found (302) will not. So that covers POST requests.

This redirect is a client-side redirect, and as such is not terrifically efficient, but it works. A server-side URL rewrite would be a vast improvement.

SOAP File locations

When Genie installs, it places a pile of SOAP files for its textbases in CS Webpublisher's \SOAP folder. We move these to DB/Text Webpublisher's \SOAP folder instead.

e.g.

c:\program files\inmagic\icsweb\soap\*.*

to

c:\program files\inmagic\webpubpro\soap\*.*

Then, in Genie's web.config, find the section called <Genie.Properties.Settings> and modify the URLs for the *.icx files to point to DB/TextWebpublisher's /dbtw-wpd/soap/ location:

<setting name="Genie_BorrowerSOAP_BORROWER_SOAP" serializeAs="String">

    <value>http://localhost/dbtw-wpd/soap/BORROWER_input.icx</value>

</setting>

Textbases

To create a DB/Text database from a CS version, create a textbase structure backup, which produces a file with a *.cbb extension. Rename the .cbb extension to .tbb. Create a new textbase from DB/Textworks and restore from the .tbb file. Now you have a DB/Text textbase whose structure matches its CS version exactly.

Then export data from the CS database as a .dmp, and use the "Load Textbase" feature in DB/Text to import it to your new DB/Textworks database. Export form elements from the CS textbase and import them into the DB/Text database.

It takes 5-10 minutes to completely re-create a CS textbase in DB/Textworks.

Conclusion

The above is an intellectual exercise, and I'm not sure what benefit might be gained by doing it, but it proves that it is possible to run Genie on DB/Text instead of Content Server, without access to Genie source code.

Mommy, why is there a server in the house?

Windows Home Server is a specialized and inexpensive file server aimed at the home market. Oh alright, I'm such a liar. It's a LOT more than a file server, because it handles

• backups,
• health monitoring,
• printer sharing,
• media streaming,
• data redundancy,
• and expandable storage for all the computers in your house, all in one package.

It's out of beta, and I want one for Christmas. (Santa? I've been a good boy. Don't listen to Sarah Parker because I so did not glue her pigtails together and anyway she deserved it for laughing at me when I threw up after eating worms.)

The real reason I'm writing about Windows Home Server is because the marketing campaign is clever and amusing: http://www.stayathomeserver.com.

There's a kind of a CNN ripoff, and this awesome "children's book":

  

There's more. Go read the book.

Failing "Catastrophically": Installing Adobe Dreamweaver CS3 Trial

I'm looking at upgrading Macromedia Studio 8 and Adobe Photoshop CS2 etc. to the latest Creative Suite 3 Design Premium Suite, but no go in testing out the trial version of Dreamweaver. Every attempt to load up what appeared to be a successful install leads to: "A problem was encountered while trying to load the trial period for Adobe Dreamweaver CS3..." followed by something like "you'll have to go online a purchase a license in order to try this out." Apparently, I'm not alone - even paid versions are having install problems. One user even claims to have lost his job because of it. And no, this is not a Vista-specific issue.

Multiple attempts (I'm persistent) to install/reinstall/remove/reinstall/hack the registry/regsvr32 DLLs/etc. all lead to the same result. So why am I writing this up? Eventually it gave up being pretty in response; now every time I attempt to load it up I get the following:

Just hilariously awesome.

Increase your vocabulary and donate rice

Ok, so this is not our normal Developer's Blog entry, but it is about development. Several of us at Andornot subscribe to a weekly newsletter from Daphne Gray-Grant, the Publication Coach and this week's newsletter got us developing our vocabulary and donating rice to hungry people for free. The stated goals of the website, freerice.com are: 1. Provide English vocabulary to everyone for free. 2. Help end world hunger by providing rice to hungry people for free. How good is that? But we warn you this addictive - thank you Daphne!