The anti-virus software that most of us are familiar with is the software on our PCs. This software typically scans files as they arrive on our PC in various ways such as sent via e-mails, that we download from the internet, and which are loaded from removable media, like CDs or memory sticks, and other more obscure ways too. They also run a periodic scan of your hard drive to check for files that have viruses that it was not able to catch on the way in, either because the virus was not known to them at the time, or they arrived by sneaky means that it was not able to detect.

The basic requirements for anti-virus checking for iRecruitment are similar to the PC requirements. We ideally want to stop any files with viruses from being uploaded, and we want to periodically check our existing files for viruses that were not known at the time of upload. It's worth noting at this point that, as of today, there are no known ways in which a virus in an uploaded file can effect the database or the server. The reason we are checking for viruses is to protect those who download the files again, not to protect the database from internal attack.

If you don't have any virus checking of the files which are being stored on the database, there are two main defenses against getting viruses when downloading the files to your PC. The first one is the most obvious - you have up to date anti-virus software on your PC. That will stop any viruses from being downloaded, provided your anti-virus software is working correctly and is up to date. The second method is simply not to download the files. Sounds flippant? Not really. iRecruitment has an excellent html view of documents, so you can look at a Word or PDF resume as html in the iRecruitment screens without ever downloading the file and exposing yourself to potential viruses.

If you don't want to rely on your PC anti-virus software being good enough then you have a few further options. If that is the case though, you probably want to start thinking about not letting your users browse any web sites outside of your company though, because there are some serious nasties out there for the unprotected. That said though, belt and braces isn't going to hurt here.

The first option is a Gateway product. Most anti-virus companies sell something like this, but the name varies between companies. What it does is it scans all your internet traffic, and - amongst many other things - it will stop a file with a virus from being uploaded to any server. That includes iRecruitment. So a product like this will automatically stop any known virus from being uploaded. There is no configuration for iRecruitment required, because this product monitors all data coming through your firewall, regardless of it's destination. Pretty neat.

The second option is the internal Symantec option. This is the option that some customers mistakenly think is what we are saying is the only option. This is not the only option, but it is the one that we had to do some special work for, as opposed to the previous options which all operate in complete independence of iRecruitment. Because we had to build code and you have to set up profile options to configure it, this is the one that you notice in our documentation.

The Symantec solution works by directly integrating with an anti-virus web service, so that iRecruitment can control the virus checking. The way this works is when a user attempts to upload a file, we stream it to the web service (typically running on one of your own servers), which validates it is virus free, and cleans or blocks it if it is not. We then either stop the upload and warn the user if the file has a virus, or save it to the database if it is clean. This is a nice user experience that integrates well with iRecruitment.

What I have described so far offers no additional security beyond the Gateway products, which all check for the incoming files. If you think about your PC solution though, it scans incoming files, and it also does a periodic check of existing files. The second thing that we therefore do though is we periodically use the web service to scan the existing files stored in the database for any virus definitions that were not known of at the time that they were uploaded. There is always a lag between virus creation time and the virus checking tools being able to detect them, so this is an important step too. If a virus is detected in an existing file, we will clean the file or delete it if that is not possible.

With this solution, the only product we have ever found which can do this is the Symantec Anti-Virus Scan Engine. This uses the open standard ICAP protocol to talk with any third party software that wants to check files. It's simple to use, and it is very effective. Some customers assume that the reason that we only directly integrate with Symantec is because we have an exclusive partnership with them (although they have been helpful, there is no formal iRecruitment partnership with Symantec, and Oracle typically avoids exclusive relationships anyway), or because we don't like other vendors (we like everyone - we are very loving people really), or because we are lazy (it's a hive of activity here. Honest!). None of those are the reason - the reason is that there are simply no other products out there that do this. We have looked long and hard, and not found any at all. If you are an anti-virus provider who does offer a similar product, please let us know, and chastise your partnership departments for not knowing about them when we contacted them. If you don't offer such a product, perhaps you want to think about building one?

And if you are a customer who is angry at us for not "supporting" your preferred vendor - don't get mad at us please. Read this article. After reading it, if you think you still need a product like Symantec's in addition to all of the other virus protection you already have, get mad at your anti-virus vendor for not providing any suitable product.

I have been persuaded that after 6 years of working on iRecruitment, it is time to hand the reigns on to someone else, and move to lead the Core HR team instead. I have owned iRecruitment development since it started way back in 2000, and have seen it go from strength to strength. I have devoted a lot of blood, sweat and tears on the product over the years, so it was a very hard decision to make the move. One of the reasons I was prepared to move is that I have Ravi Banda as an excellent replacement, and I am sure he will do a great job of taking the product forward. I'll be keeping an interest in what is going on with iRecruitment, and I am sure that in my new role I will stay involved with many of my iRecruitment friends, both in Oracle and externally.

My new Core HR role is like a blast from the past for me since I managed part of the Core HR team before starting iRecruitment. My new role here is a great new challenge though. My team is responsible for the Person part of the HCM product, along with most things that belong to a person (e.g. their employment details, contacts, addresses and the like). I will be leading the team through the transition to Fusion, where our first big goal is to enhance our schema to take advantage of some global person concepts from PeopleSoft that we think will be of benefit to everyone, and give us a great platform to move forward on..

Last Friday we released our latest round of functionality, IRC.E RUP1 (patch 5061111). This is a great new released that contains some new functionality that we know that many of you have been waiting for. This includes;

• Assessments
  Assessments integrates iRecruitment with iLearning to allow you to set up tests, either scored or non-scored, and to have a test be taken when a candidate registers, and when they apply for a vacancy. You can set up different tests on a vacancy by vacancy basis too. Managers can then see the results of the tests, and for example just see people who have passed a test.


• Vacancy Approvals
  Approvals in the vacancy process has not changed very much since it was first released, while the approvals in the new Offers functionality in IRC.E is significantly more advanced. We really wanted to bring the new advanced approvals functionality in to the vacancy area too, so in IRC.E RUP1 we re-wrote the vacancy approvals process to use the same common approvals code as Offers. This offers a number of advantages, such as;
  




• The Vacancy workflow is now just used for approvals, not navigation, making it less prone to change as we add new functionality. This means that if you create a copy, it is less likely to need to be updated in future.


• You can now add dynamic approvers and people to receive FYI notifications


• Comments are routed better


• We have set up the approval rules so that you can modify them more easily - you can add new rules within our seeded transaction, without modifying the seeded transaction


• More types of AME transaction are supported (e.g. position hierarchy).


• Allow my account to be searched
  For those of you who want to default the Allow My Account To Be Searched checkbox to Yes, we have added a profile option to do that


• Applicant Search
  On the applicants for vacancy screen, we have made a few enhancements to make it easier to use. We have added the options of viewing rejected and hired applicants as well as the existing default of active applicants. We have also changed the assignment status criteria on this page to be based on a poplist rather than free text, so you don't have to remember what the statuses were called. These changes also meant a change in the applicant details screen, where you can choose between displaying a list of their Active applications or All applications (i.e. rejected and hired too). Which of those you see depends on whether or not you drill down to see an active assignment (default is Active in this case) or a rejected or hired assignment (default is then All). Sounds complicated, but is obvious in practice.


• Online Help
  We have added online help to about 40 of the manager pages. This helps them understand the concepts and ideas, as well as the detailed steps in using iRecruitment. This requires patch 5348564.

As well as all of that, we have done a number of bug fixes and minor enhancements, to make this our best release yet. The whole team are really proud of what we have built here, so we hope you all download it and upgrade to it soon! Have a look on metalink for more details. The About Doc is note number 373827.1, and the new implementation guide is note number 373837.1. Both contain far more information than in this article, so please have a read.

For those of you who are confused by the name of the release, let me explain. We are no longer releasing mini-packs on 11i. Instead we are releasing rollup patches. They can contain a similar level of new functionality and bug fixes, but they are not a cumulative patch like the mini-packs were. This makes them smaller and more manageable, but means that they can only be applied on top of the last mini-pack. If you are not currently on IRC.E, when you apply IRC.E RUP1, you must either apply IRC.E first, or merge the two patches together and apply as one.

I am back again after 2 weeks of paternity leave. My wife and I had a new baby, called William Robert, on the 24th May, weighing 7lb 6oz

Obviously I am delighted, and thanks to everyone who has sent congratulations.

I am going to be out of the office for a couple of weeks on paternity leave. That's right - I am going to be a dad again. Hopefully we should have our new arrival this week, and then I'll be off helping my wife look after a toddler and a newborn. Fortunately I'll be back in a couple of weeks, and I'll be raring to get back in to the office for some well deserved peace and quiet. In the meanwhile, the iRecruitment development team will be in great hands, and will be working harder than ever.

UPDATE: Wow - it was only 2 1/2 hours after this post that the baby was born.

A skin consists of two components. The first are the Renderers, which define where on the screen items are placed, and the html around the core items. The second are the styles, which define how the common components on the screen actually look, e.g. the appearance of the tabs and the buttons.

Renderer

First of all we will create a Renderer for our pages. This defines the layout of the actual pages. To create this, we need to create a new directory for the skin in the $OA_HTML/cabo/templates directory. In this example, I am going to create an example based on the OTN web site (http://otn.oracle.com/), so I create a directory called $OA_HTML/cabo/templates/otn-desktop

In that directory, I create a file called pageLayout.uit. This is the file which is going to define the layout of the page, and add the html components that I want around the dynamic parts of the screen. There is a good description of the contents of this file at http://www.oracle.com/technology/products/jdev/howtos/10g/adf_uix_laf_ht/index.html. The pageLayout.uit file defines the overall layout of your page in uix format. Here is my example based on OTN. I created it by going to the http://otn.oracle.com/ web site, and doing a View Source from my browser. I then edited the html to make it XHTML compliant (uit documents need to be valid xml), and adding in the markers for the rendered components on the page, for example the xml string <ui:rootChild name="contents"/> tells the page where to put the core contents of the page. The file I created can be found here.

It is not necessarily trivial to make your file xml compliant, and if it is not, your template file will not be used, and the system will revert to the default template. If this happens, you can check your jserv.log file for any errors in the template file.

The next step I took is to log in to the applications and in the Custom Look And Feel Administrator responsibility, I create a new Look and Feel, with the following parameters;

Name: otn-desktop
Family: otn
Description: sample otn skin 
Base Look and Feel: simple.desktop

I then navigate through the rest of the flow without changing any of the parameters, to set up the skin with just the layout changed.

Finally, we need to tell this new skin to use the pageLayout.uit renderer that we created. When the skin was created, a file called otn-desktop.xml will have been created in $OA_HTML/cabo/lafs. I edited that file to have the following content. Basically I just added the renderers content to tell it to use the pageLayout.uit file.

<look-and-feel style-sheet-name="otn-desktop.xss"
xmlns:otn-desktop="http://xmlns.example.org/laf/otn"
xmlns="http://xmlns.oracle.com/uix/ui/laf"
family="otn" extends="simple.desktop" id="otn-desktop">
<renderers>
<renderer name="pageLayout">
<template name="pageLayout.uit">
</template>
</renderer>
</renderers>
</look-and-feel>

To test the skin, I create a new user, and change the Oracle Applications Look and Feel profile option at user level for my new user to have a value of otn-desktop. I then bounce the application server, and log in as the new user. I see the layout of the responsibility page as follows;

Styles

This looks OK, but I also want to change some of the colours and the font size, so I go back in to the Custom Look And Feel Administrator responsibility, and I update the otn-desktop style to set some properties against the global component as follows;

Style: DefaultFont
Property: font-size
Value: 9pt

Style: DarkBackground
Property: background-color
Value: #000033

After doing this, log out, then I delete the stylesheet cache as follows;

rm $OA_HTML/cabo/cache/otn*

and then log back in again, and the new styles get picked up, making the screen look as follows;

Finally, I want to change some of the graphics on the screen. In particular, I want to change the way that the tabs are rendered, to make them look like boxes, so in the Custom Look And Feel Administrator responsibility, and I update the otn-desktop style to set the following properties against the tabBar component's Icons;

tabBarSelectedEnabledJoin,
tabBarEnabledSelectedJoin, 
tabBarEnabledJoin,
tabBarSelectedEnd, 
tabBarSelectedStart,
tabBarEnabledEnd, 
tabBarEnabledStart
URI: join.gif
Height: 30
Width: 1

tabBarSelectedBackground
URI: selected_middle.gif
Height: 30
Width: 1

tabBarEnabledBackground
URI: enabled_middle.gif
Height: 30
Width: 1

I then create a directory, $OA_HTML/cabo/images/otn_desktop, and I upload my gifs to use for the tabs to that directory. I then bounce the application server, and I see tabs like this;

Using the simple techniques shown here, you should be able to create a skin for iRecruitment which closely matches your corporate look and feel - setting the page layout the same, as well as the colours and graphics. If you create a nice skin, please post a URL to your recruiting site so that we can see it in action.

I recently had an interesting question from a customer who was looking to post to some job boards who accepted XML input, but who did not support the standard HR-XML format. This is an interesting challenge for many companies. Indeed, even job boards who accept HR-XML formatted data may be a challenge since they may want specific attribution, e.g. locations or job categories which the define. Fortunately there is a simple solution to this, which I am reproducing here:

There are two problems to be overcome here. The first is to get the outgoing data in the correct format. This is something that is possible to do fairly well with our stylesheets, which allow you to transform the data in to any format, as long as you don't want to significantly alter the actual data values. If you do need to significantly alter the data, this is not trivial to do in a stylesheet.

The second problem is that we only accept an HR-XML response, and are not flexible about the format of that. Any other response will result in an error code being displayed (IRC_412087_TP_BAD_VENDOR_XML), and the posting URL will not be recorded.

A simple way to solve both of these issues is to create a basic interface between iRecruitment and the job board, which translates the data in and out. This sounds complex, but with basic scripting languages such as perl, or jsp, this is very easy to do. We will demonstrate with a worked example.

First of all, we want to create a stylesheet to translate our data in to a format that is as near as possible to the desired format. In this case, we want an output like this;

<xml version = "1.0"?>
<PostJobDataSet>
<Users>
<UserName>bob</UserName>
<Password>secret</Password>
<Jobs>
<title>Software Engineer</title>
<short_desc>This is a software engineer job</short_desc>
<long_desc>This is a software engineer job.
What a great job!</long_desc>
<location>READING, UK</location>
</Jobs>
</Users>
</PostJobDataSet>

To do this, we create a simple stylesheet in the $OA_HTML, called JobPost1.xsl

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet 
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output  method="text" indent="yes" />
<xsl:template match="jobpositionposting">
<xsl:for-each select="row"><?xml version = "1.0"?>
<PostJobDataSet>
<Users>
<UserName><xsl:value-of select="posting_username "/></UserName>
<Password><xsl:value-of select="posting_password "/></Password>
<Jobs>
<title><xsl:value-of select="job_title"/></title>
<short_desc><xsl:value-of select="brief_description"/></short_desc>
<long_desc><xsl:value-of select="detailed_description"/></long_desc>
<location><xsl:value-of select="town_or_city"/></location>
</Jobs>
</Users>
</PostJobDataSet>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

This stylesheet will create the data in the format that we want, other than the location, which will be in lower case.

We then create a simple perl script as follows, called postData1.pl. This can be placed in any cgi-bin directory inside your firewall.

#!/usr/local/bin/perl -w

use CGI::Carp qw( fatalsToBrowser );
use CGI;
use HTTP::Request::Common qw(POST);
use LWP::UserAgent;

# look at the request method
my $method = $ENV{'REQUEST_METHOD'};
my $text;
# get the submitted string
if ($method eq "GET") {
    $text = $ENV{'QUERY_STRING'};
}else { 
# default to POST
    read(STDIN, $text, $ENV{'CONTENT_LENGTH'});
}  

#find the xml tag in the posted text
$locstart=index($text,"<location>");
if($locstart>0) {
 $locend=index($text,"</location>");

 #get the location value
 $locationtext=substr($text,$locstart+10,$locend-($locstart+10));

 #manipulatethe location value and create the new xml
 $newlocation=uc($locationtext);
 $newxml=substr($text,0,$locstart+10);
 $newxml=$newxml.$newlocation.substr($text,$locend);
} else {
 $newxml=$text;
}

# create the post to the new URL
$ua = LWP::UserAgent->new();
# enter your proxy server here if applicable
$ua->proxy('http','http://www-proxy.us.oracle.com:80');
my $req = POST 'http://www.yahoo.com',
               [ xml => $text];
#read the response
$response=$ua->request($req);
if($response->is_success()){
  # if successful, process the response to get the data out
  $content = $ua->request($req)->as_string;
  # you should add a check here for success
  $statuscode="200";
  $statusdesc="Success (ok)";
  # you should add the correct processing here to pull the URL 
  # from the response if it was a success
  $respURL="http://www.test.com/post?id=1";

} else {
  # the post failed, so get the http error code
  $statuscode=$response->code();
  $statusdesc=$response->message();
  $respURL=$response->status_line;
}

#create the translated response
$myresponse="<?xml version = \"1.0"?>
<Envelope version = "01.00">
  <Sender> 
    <Id>postTest</Id> 
  </Sender>
  <Recipient>
    <Id>postTest</Id>
  </Recipient>
  <TransactInfo type= "response">
    <TansactId>1</TansactId>
    <TimeStamp>2000-01-01T00:00:00</TimeStamp>
    <Status>
      <Code>$statuscode</Code>
      <ShortDescription>$statusdesc</ShortDescription>
    </Status>
  </TransactInfo>
  <Packet>
    <PacketInfo packetType = "response">
      <PacketId>1</PacketId>
      <Action>OracleHRMSJobPosting</Action>
      <Manifest>URL</Manifest>
    </PacketInfo>
    <Payload>$respURL</Payload>            
</Packet>
</Envelope>";

#send the response back
print "Content-type: text/xml\n\n";
print $myresponse;

This script will take the xml that it receives, change the location to be upper case, and then post it to another URL. When it gets the response, it will look at the response and create an HR-XML style message based on that, and then send that message back to the application server.

To put this all of this in to action, you then just need to create a new recruiting site, where the posting URL is the URL of your perl script, and the stylesheet is JobPost1.xsl. The script is then called by iRecruitment when you post an advert, and will act as an intermediary between iRecruitment and whatever format the job board chooses to use.

You can create as many copies of the script as you have job boards, editing the URL and the formatting based on the requirements of each job board. You will note that none of this required any customization of any Oracle code, so is not going to be effected by any patches or upgrades either. That's the beauty of web services!