TCC – SSO Errors
In the URL when testing SSO, if something goes wrong you’ll get an errorReason=X, the reason codes are listed here:
In the URL when testing SSO, if something goes wrong you’ll get an errorReason=X, the reason codes are listed here:
A lot of times you need to make an update on a description or a text field. Let’s say you want to concatenate a new statement at the bottom for the requisition or template that specifies EEO compliance.
Now we all know what fun it is to try to manually do anything with those fields so I just say don’t do it.
Instead use Taleo GUI to craft what you are looking for in the filed you are looking to place it in within the staging zone (i.e. if you want change/add to JobInformation,DescriptionExternalHTML then create your content in the JobInformation,DescriptionExternalHTML field, although this isn’t needed it’s best practice down the road for the import, just trust me on this one)
So when you get your export it’s going to be the Taleo HTML that we all know and love, but how in the world are you supposed to get it into an export to update everything?
This is where our friend CDATA comes in. CDATA stands for Character Data and it means that the data in between these strings includes data that could be interpreted as XML markup, but should not be.
<quer:string>
<![CDATA[Taleo_HTML]]>
</quer:string>
You may also need to set the projectedValueType to string.
When testing before the standard login is shut off you may need to bypass which is such:
https://zone.taleo.net/smartorg/iam/accessmanagement/login.jsf?redirectionURI=https%3A%2F%2Fzone.taleo.net%2Fsmartorg%2FTaleoHomePage.jss&TARGET=https%3A%2F%2Fzone.taleo.net%2Fsmartorg%2FTaleoHomePage.jss
Oracle has announced that they are ending support for SHA-1 and migrating all it’s products to be SHA-2 compliant. Today they have released the information needed in order to accomplish this.
TCC-TCB SHA-2_CustomerDocument_Final is the Oracle white paper on the migration.
A shout out to Kelly Amott for bringing this to resolution. I’ve always wondered what the difference between the the requisition reopen and reactivate operations and there’s not a bunch in the documentation that I’ve seen that would explain it. He got the answer from a case and was kind enough to share.
Update and FYI – To take the req off hold I was using the Requisition – reopen spec. Oracle advised that reopen is for cancelled reqs. The specification I needed to be using is the Requisition – reactivate.
Occasionally I get the question if you can update candidate EEO information. The answer is yes but it’s tricky. The key is in Doc ID 1047686.1 which states:
To import Diversity Answers, a unique ID is necessary for both Question and PossibleAnswer. Unfortunately, the Code does not enforce uniqueness, so sometimes another field is needed to use in imports. The field Number is available for both PossibleAnswer and Question entities even if it isn’t presented in the feature pack. To use them, just drag another field from the entity and edit the Path to Number.
Run an export on Possible Answer and Question numbers in order to know what IDs to use in your imports.
I ran across an issue where a client had usernames that were all supposed to be lower but somehow wound up as a mixed case username.
The SQL we would use would work out something like this…
Select
Number,
Username,
LOWER(Username)
WHERE
Username != LOWER(Username)
To illustrate this here is the export specification that would return the above mentioned in TCC, name of file CandidateExportTestLower_sq.xml
Contents:
<?xml version="1.0" encoding="UTF-8"?> <quer:query productCode="RC1501" model="http://www.taleo.com/ws/tee800/2009/01" projectedClass="Candidate" locale="en" mode="CSV" csvheader="true" largegraph="true" preventDuplicates="false" xmlns:quer="http://www.taleo.com/ws/integration/query"> <quer:subQueries/> <quer:projections> <quer:projection> <quer:field path="Number"/> </quer:projection> <quer:projection> <quer:field path="Credentials,Username"/> </quer:projection> <quer:projection alias="UsernameLower"> <quer:customFunction name="LOWER"> <quer:field path="Credentials,Username"/> </quer:customFunction> </quer:projection> </quer:projections> <quer:projectionFilterings/> <quer:filterings> <quer:filtering> <quer:notEqual> <quer:field path="Credentials,Username"/> <quer:customFunction name="LOWER"> <quer:field path="Credentials,Username"/> </quer:customFunction> </quer:notEqual> </quer:filtering> </quer:filterings> <quer:sortings/> <quer:sortingFilterings/> <quer:groupings/> <quer:joinings/> </quer:query>
I don’t know why but I can never figure out what the date should be when importing it.
It needs to be the format of:
YYYY-DD-MM
There are three items that we need to take a look at in regards to upgrading TCC.
The first in the version of your current zone in relation to Recruiting, Transitions and Performance. These are usually in sync with one another and denoted by the year released and an A/B version of the release (e.g. 14A, 14B, 15A). This information can be ascertained from the GUI by clicking resources > about.
This version will be the target version for TCC so if your zone is on 15A, we’ll be upgrading TCC to version 15A.
The next item of concern is the installation of the the latest version of TCC and corresponding Application Data Model (Feature Packs). These can be obtained from https://edelivery.oracle.com and a tutorial of the installation can be found here.
TCC versions can be installed side by side with no issues. This assumes that you will utilize a separate directory for each of the installations. The TaleoConnectClient.bat file will be what needs to be called from the batch files in order to utilize the new version, this file is in the root of the installation directory.
The last item we need to address is the version of the scripts themselves. Every script (*_sq.xml = export, *_ld.xml = import, *_cfg.xml = configuration) will have an attribute called productCode in the XML file. It will look like this:
productCode=”RC1401″ for imports and exports
and
These codes are documented on the Oracle support site in Doc ID 1044000.1
In this case we can see that these integrations were built under 14A. These scripts will have to be manually updated via a text editor to change the RC1401 to RC1501 which corresponds to TCC 15A. It is highly recommended that this is done first on a staging server pointed towards the staging zone. The issue that could possibly occur is that if any fields have been deprecated and those are associated with an integration, it will cause the integration to fail. Conversely, if new fields are added you will need the version of TCC that the enhancement was released in order to utilize the new field.