Scheduling XAgents on a Linux box using Cron

We used scheduled code in our XPage apps to do things like pre-building dashboards and storing the data in the application scope.

There is no simple way to schedule Java code that has been written for use with XPages. The best solution I have found has been to use “XAgents” and to poll the corresponding URLs somehow.

I have tried this using various methods but it has not been straight forwards due to authentication issues and having to deal with SSL certificates.

The best solution I have come up with to date is to use the linux “cron” task and the wget command which is typically used to download data via the web.  This can be configured using the crontab -e command line utility or easier still by using webmin.

Step 1 – create an internet site mapped to localhost. On this site disable session authentication as it seems to cause spurious issues with automated remote calls. Also disable any settings that force traffic to use SSL.

Step 2 – from the command line in linux test your proposed wget command – something like :

wget –user=USERNAME –password=XXXX “http://localhost/apps/aw.nsf/xp_f_process_bad_actors.xsp?source=Cron”

Step 3 – add this as a scheduled task using crontab -e or webmin as shown below

@hourly wget –user=USERNAME –password=XXXX “http://localhost/apps/aw.nsf/xp_f_process_bad_actors.xsp?source=Cron”

2015-10-20_17-52-35

Additional Notes

The download files when you run test downloads from webmin will be stored in /usr/libexec/webmin/cron/.. although if you schedule the task with a user such as Apache ( as shown above ) then no file is actually saved because of a permissions failure

The cron log is at /var/log/cron

Your Domino username and password will be stored in plain text in the crontab files and in the logs

You could also use bash script files and schedule these via Domino Program Documents

Thoughts for a future iteration

Making the trigger urls accessible via an anonymous user using sessionassigner somehow

 

 

Upgrading Domino causes issues with CKEditor for Chrome users

We have had a spike in help desk calls with general “oddness” in one of our XPage applications. This has been triggered by an upgrade to the Domino server that included a new CKEditor version.

It seems as though Chrome ( possibly other browsers ) cache the old CKEditor files in the browser and these are not compatible with the new server version.

Users of the XPage in edit mode see the following malformed page even after several days.

2015-07-23_14-21-35

 

The immediate solution is to get the user to delete their cache – not an easy task nor one that presents a good impression as a service provider 🙁

Users can do this by using CTRL _+ SHIFT + DELETE and then selecting the following options

2015-07-23_14-26-33

Allowing the user to use the default settings will make you very unpopular as they will loose lost of useful cached history.

I tried the simple delete cookies option but that didn’t work.

Although this post focuses on the CKEditor we have experienced other “general weirdness” after upgrades. These are usually sorted after clearing the cache. Per Henrik Lausten has posted a good scheme to minimise these issues but he says it does not help with the CK Editor issue.

Presumably that would require IBM to change the resource names for each CK editor release although it does look as though at least some of the files do have a suffix that may be for that purpose

2015-07-23_14-34-27

Changing the nsf file path will not help as the resources are served centrally as the highlighted blue detail shows.

If anyone has any better ideas or understanding of this please shout. It causes a lot of hassle and presents a poor impression when you need to tell people to clear the cache – especially when you are providing an external service.