Category TCC

Here’s how:

Add this to the environment file:
SET RESPONSE_FOLDER=..\..\data\response

Then add this to the tcc.bat:
SET JAVA_OPTS=%JAVA_OPTS% -Dcom.taleo.client.symbol.RESPONSE_FOLDER=”%RESPONSE_FOLDER%”

Then add this to the TCC_GUI.bat:
call :makeAbsoluteShortName RESPONSE_FOLDER
>>”%TCC_HOME%\TaleoConnectClient.ini” echo -Dcom.taleo.client.symbol.RESPONSE_FOLDER=%RESPONSE_FOLDER%

Configuration, export and import files refer to product integration packs through an alpha-numeric code.|

Read More

Found a great explanation on the subject here, posted it here for posterity.

This is an unfortunate misnaming perpetrated by Windows.

Because Windows uses UTF-16LE encoding internally as the memory storage format for Unicode strings, it considers this to be the natural encoding of Unicode text. In the Windows world, there are ANSI strings (the system codepage on the current machine, subject to total unportability) and there are Unicode strings (stored internally as UTF-16LE).

This was all devised in the early days of Unicode, before we realised that UCS-2 wasn’t enough, and before UTF-8 was invented. This is why Windows’s support for UTF-8 is all-round poor.

This misguided naming scheme became part of the user interface. A text editor that uses Windows’s encoding support to provide a range of encodings will automatically and inappropriately describe UTF-16LE as “Unicode”, and UTF-16BE, if provided, as “Unicode big-endian”.

(Other editors that do encodings themselves, like Notepad++, don’t have this problem.)

If it makes you feel any better about it, ‘ANSI’ strings aren’t based on any ANSI standard, either.

Ran across this and it took me a while because of the dot notation that they are using in the path, seems you can just ignore it and use it as part of the path.

<quer:filtering xmlns:quer="http://www.taleo.com/ws/integration/query">
<quer:or>
<quer:equal>
<quer:field path="Candidate,History,ApplicationTrackingHistoryItem.CreationDate"/>
<quer:query projectedClass="Application" alias="histItemSubQuery">
<quer:projections>
<quer:projection>
<quer:maximum>
<quer:field path="Candidate,History,ApplicationTrackingHistoryItem.CreationDate"/>
</quer:maximum>
</quer:projection>
</quer:projections>
<quer:filterings>
<quer:filtering>
<quer:equal>
<quer:field ownerQuery="histItemSubQuery" path="Number"/>
<quer:field ownerQuery="NewHire" path="Number"/>
</quer:equal>
</quer:filtering>
</quer:filterings>
</quer:query>
</quer:equal>
<quer:isNull>
<quer:field path="Candidate,History,ApplicationTrackingHistoryItem.CreationDate"/>
</quer:isNull>
</quer:or>
</quer:filtering>

I recently came upon a situation where we needed the start date but because the offer module not being used, we needed to get it from the history.

Here is where it lives:
Candidate,History,ApplicationTrackingHistoryItem.Detail

and you have to filter on the event code:
Candidate,History,ApplicationTrackingHistoryItem.Event,Code

There are times that you want to just return some text in an export column. This comes in handy when let’s say you’re exporting job templates and need to put in a new code. In any case if you need it you can use this snippet to do so:

<quer:projection alias="Test" xmlns:quer="http://www.taleo.com/ws/integration/query">
 <quer:string>ThisIsIt</quer:string>
</quer:projection>

I got asked today if it was possible to return just those users who had one group and that group was the main group.  I wasn’t able (yet) to use the count function in the filter so what I did was this:

I returned UserNo, keyCount (count of UserAccount,Groups,Name).
I added a filter to equal the string main group.
In the resultant file, the users who had a count of 1 would only be in the main group.

This isn’t ideal but it does give a list of those who are only in the main group with a little massaging.  Attached it the export file for this process.

UserExport_sq

Okay, the last one I published doesn’t have the cut and paste ability for the complex filter, so here it is:

<quer:filtering xmlns:quer="http://www.taleo.com/ws/integration/query">
 <quer:or>
 <quer:equal>
 <quer:field path="UserAccount,Groups,Name"/>
 <quer:string>usmagn</quer:string>
 </quer:equal>
 <quer:equal>
 <quer:field path="UserAccount,Groups,Name"/>
 <quer:string>uspacs</quer:string>
 </quer:equal>
 </quer:or>
</quer:filtering>

One of the most general errors you will encounter in TCC is the dreaded SAX parsing error.  It happens often and gives you no clue as to what went wrong.

The way to get it to give you the details of the error is to go into the post processing tab of the config file and uncheck the ‘Fail on export error’ checkbox.  While this won’t fix the error it will now return the error (more specifically the field that’s causing the error) in the response file.

This applies to the encoding of the file that TCC produces for the response.  Let’s say you need it in something other that UTF-8.  In this case we’d like to see it in ISO-8859-1.  First you have to specify the response encoding in the configuration general tab:

If you were to save and run at this point, it will fail.  In the manual you will find this on the subject:

The Encoding states the way the file is encoded. The Taleo environment only supports UTF-8 encoding.
Conversion is available in the Pre- and post-processing steps. -p55 TCC-13B-UserManual

This means that there needs to be a post processing step to change the encoding, fortunately it’s a pre-populated function called ‘Convert Encoding’.  Simply add that into the post processing step after the Strip SOAP step as shown below and you’re good to go.