Archive for the ‘Automation Server’ Category

Happy New Year 2013! Y2k13 bug time…

Thursday, January 3rd, 2013

From your friends at Integryst, Happy New Year!

It’s been a while since I last posted, and thought an appropriate way to kick off the new year was to share a Y2k13 bug in WebCenter Interaction. Well, it’s not a bug per se, but way back in the augts, 2013 seemed a long way away. So the wise developers at Plumtree, when faced with choosing a date infathomably far in the future, chose January 1, 2013 as the hard-coded expiration time for Automation Server Jobs:

This means two things: First, when creating jobs on your ancient WebCenter Interaction/Aqualogic User Interaction/Plumtree portal, you’ll have a couple more clicks to set the “Do Not Run After” value sufficiently far in the future, or you’ll get an error saving the job because the expiration time is in the past. (2015 is plenty far, right? If you’re not feeling that lucky, I suggest 2099 so your grandkids can worry about the Y3k bug).

The second thing it means is that many of your jobs probably stopped running three days ago, because when you created them you probably left the default value in there for the expiration time. There’s no quick fix for this, but after the break I’ll share some tips on how you can reschedule these jobs. (more…)

Update WebCenter Content Crawler and Job Owners

Tuesday, October 26th, 2010

As the portal evolved from Plumtree to ALUI (AquaLogic User Interaction) to WCI (WebCenter Interaction), there’s been a legacy feature that was born with good intentions, but like many things in human physical anatomy, it has survived evolution with little to no value.

This feature is object “owners” for Content Crawlers and Automation Jobs.  I’m sure there was a grand intent at some point for “owners” to mean something, but I haven’t found it yet.

The “owner” is the portal user that is scheduled to run a job.  But if that user is later deleted, the portal doesn’t clean up after itself – and all jobs that the user created are “orphaned” and won’t run, showing an error in PTSpy like:

Sep 12, 2010 10:07:02 PM- *** Job Operation #1 of 1 with ClassID 38 and ObjectID 202 cannot be run, probably because the operation has been deleted.

The fix – which I will condone until I can figure out why jobs need “owners” in the first place – is to just make the owner of all jobs and crawlers the Administrator user. The Administrator user can’t be deleted, and since I haven’t found any problems with running a crawler as this user, you can just do a portal-wide update making this change with the following SQL:


Helpful SQL to determine if you’re being bitten by this “vestigal organ” after the break.


Updating the Location of a Crawled Card in WebCenter Interaction

Friday, September 24th, 2010

Much has been written on Content Crawlers and Cards in Plumtree’s Knowledge DirectoryChris Bucchere has done an excellent writeup on creating custom crawlers, and Ross Brodbeck has done the same for cards in the Knowledge Directory.  In fact, as I re-read those two articles, I realize this post addresses open issues in both articles – how to change the location of a card, and what the Location CRC values are within a card.

In the spirit of giving credit where credit is due, today’s post is based an excellent tip I learned recently from Fabien Sanglier, who figured out this little gem long before I did, and I believe had even posted code on his ALUI Toolbox project.

First, a word on crawlers:  basically, WCI’s Automation Server just calls several methods in a crawler to perform the following (I’m heavily paraphrasing here):

  1. Open the root path specified in the crawler’s SCI Page and query for “containers” (a.k.a., folders).
  2. Query that container for all “documents” (a.k.a., cards, which don’t necessarily have to be files).
  3. Recursively iterate through each container and query for the documents within each.
  4. For each document found, query for document signature and document fetch URL.
  5. If the document signature or path has changed, flag the card as changed and refresh it (which could be metadata, file content, or security)

Later, the Document Refresh and Search Update jobs will also use that crawler code to keep track of whether documents have changed in the source repository (by checking the document signature), and whether the document has moved.  If the signature hasn’t changed, the card remains untouched:

Now, let’s say you need to change the path of an NT Crawler because you’re moving those documents elsewhere.  Normally, you’d just move the files and change your crawler’s root path.  The problem with this approach is that the crawler won’t be able to recognize these files as the same ones that are in the Knowledge Directory, because the path has changed.  Consequently, all cards will be deleted and recreated.  This may not be a problem, but if your Content Managers are like any other Content Manager since the Plumtree days, there will be a lot of portlets that link to these documents in their content.  These links will all be broken, because new cards mean new Object IDs, which are part of those URLs (even the “friendly” ones).

The (partial) solution?  Update the paths for the crawlers AND cards through the API, so that the next time the crawler runs, the portal isn’t aware of any changes and doesn’t mess with any of the already-imported cards because the signatures match up.

Here’s the rub, though: not only does the Automation Server check to see if a document’s SIGNATURE has changed (in an NT File Crawler, for example, the signature is just the “last-modified” date), but it also checks to make sure the document’s PATH has changed.  In other words, if a card has an internal path of \\oldfileshare\folder1\mydoc.doc, and you programmatically change the crawler AND the cards to use \\newfileshare\folder1\mydoc.doc, the cards will STILL get wiped out and crawled in as new.  This is because the portal maintains a CRC check of the old document path, so that if it changes, it knows it’s looking at a different document.

Unfortunately, there doesn’t seem to be a way to update this CRC value through the API, so you need to use a direct DB update to make the change.  Below is the code used to generate the CRC and the table where it needs to be updated.  In my next post, I’ll include a more comprehensive listing.

int crca = XPCRC.GenerateCRC64(strCardLocation).m_crcA;
int crcb = XPCRC.GenerateCRC64(strCardLocation).m_crcB;

DbCommand updateComm = oConn.CreateCommand();
updateComm.CommandType = CommandType.Text;
updateComm.CommandText = "update ptinternalcardinfo set locationcrc_a = " + crca + ", locationcrc_b = " + crcb + " where cardid = " + card.GetObjectID();

Changing the Server Name for Automation Server

Thursday, July 29th, 2010

It’s not without some controversy (OK, “spirited discussion”), but I’ve strongly recommended the use of host files to aid environment portability.  If you’re a believer in this “alias” approach, you’ll find that for some components, it isn’t very obvious how to set up those aliases.  This isn’t quite a host file hack, but serves the same purpose:  when you migrate the database from one environment to the other, you want to avoid having to change as many settings as possible.

One of these settings is the ALUI Automation Server: in “Select Utility: Automation Service”, you get a list of servers running the Automation Service, and can set which administrative folders are associated to which Job (aka Automation) Servers.  If you migrate the portal database between environments, you might have one entry show up for “PRODPORTAL3” (in prod) and another for “PORTALDEV9” (in dev).  But then in the dev environment you have to re-register every one of the folders that was associated with the prod folder. 

What if you could just create an alias that worked in both environments?  Fortunately, you can, and the tweak is easy:  Just edit %PT_HOME%\settings\configuration.xml in both environments, and change the value below to be the same thing.  Then, when the automation server in either environment starts up, it’ll look for jobs registered with that same name:

<component name="automation:server" type=" config/component/types/automation">
<setting name="automation-server:server-name">
<value xsi:type="xsd:string">WCI-AUTOMATION</value>

Oh, and if you’re a “UI” kind of person, you can achieve the same result by changing the name through the Configuration Manager: