Posts Tagged ‘Automation’

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:
wci-create-job

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:

UPDATE PTCRAWLERS SET OWNERID=1
UPDATE PTJOBS SET OWNERID=1

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

(more…)

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="http://www.plumtree.com/ config/component/types/automation">
<setting name="automation-server:server-name">
<value xsi:type="xsd:string">WCI-AUTOMATION</value>
</setting>

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