Category TCC

I can’t believe I jacked with this process for a stinking hour before I stumbled on the the right combination. Use the below XML to create the _ld.xml file.

<?xml version="1.0" encoding="UTF-8"?>
<load:load productCode="RC1401" model="http://www.taleo.com/ws/tee800/2009/01" root="UDSElement" operation="delete" locale="en" header="true" delimiter="," quote="&quot;" xmlns:load="http://www.taleo.com/ws/integration/load">
    <load:columns>
        <load:column parameter="1" type="DATA" path="UserDefinedSelection,Code" searchType="SEARCH" searchTarget=".." localeType="NONE"/>
        <load:column parameter="1" type="DATA" path="Code" searchType="SEARCH" searchTarget="." localeType="NONE"/>
    </load:columns>
    <load:processingInstructions/>
</load:load>

Not sure why the diversity questions are nested the way they are as opposed to the questions. Diversity questions are the canned questions related to EEO, if the client is using those you have to get the answer from the diversity questions element. Here is a sample of how it works:

<quer:projection id="idEEO2OtherProtectVetAnswerNo" alias="OtherProtectedVetAnswer" xmlns:quer="http://www.taleo.com/ws/integration/query">
  <quer:query projectedClass="Candidate" alias="CandOtherProtectVetNo">
    <quer:projections>
      <quer:projection alias="EEO2OtherProtectVetNo">
        <quer:decode>
          <quer:field path="DiversityAnswers,PossibleAnswer,PossibleAnswerType,Number"/>
          <quer:integer>291</quer:integer>
          <quer:string>Y</quer:string>
          <quer:integer>292</quer:integer>
          <quer:string>N</quer:string>
          <quer:integer>2</quer:integer>
          <quer:string>X</quer:string>
          <quer:integer>1</quer:integer>
          <quer:string>NS</quer:string>
        </quer:decode>
      </quer:projection>
    </quer:projections>
    <quer:filterings>
      <quer:filtering>
        <quer:equal>
          <quer:field path="DiversityAnswers,Question,Number"/>
          <quer:integer>12232093</quer:integer>
        </quer:equal>
      </quer:filtering>
      <quer:filtering>
        <quer:equal>
          <quer:field path="Number"/>
          <quer:field ownerQuery="NewHire" path="Candidate"/>
        </quer:equal>
      </quer:filtering>
    </quer:filterings>
  </quer:query>
</quer:projection>

When you are looking to return the value of a disqualification question in TCC the below code will work.  This is out of transitions.

<quer:projection id="idAuthToWorkUS" alias="UWH_LEGALLY_AUTH" xmlns:quer="http://www.taleo.com/ws/integration/query">
  <quer:query projectedClass="Candidate" alias="AuthToWork">
    <quer:projections>
      <quer:projection alias="idAuth_To_Work_US">
        <quer:field path="ProfileInformation,Candidate,QuestionAnswers,Answer,Description"/>
      </quer:projection>
    </quer:projections>
    <quer:filterings>
      <quer:filtering>
        <quer:equal>
          <quer:field path="ProfileInformation,Candidate,QuestionAnswers,Question"/>
          <quer:string>5053</quer:string>
        </quer:equal>
      </quer:filtering>
      <quer:filtering>
        <quer:equal>
          <quer:field path="Number"/>
          <quer:field ownerQuery="MainQuery" path="ProfileInformation,Candidate"/>
        </quer:equal>
      </quer:filtering>
    </quer:filterings>
  </quer:query>
</quer:projection>

Transitions is easy to export out of because of the fact you build every filed that you need.  Unfortunately you sometimes have to dig it out of the candidate data if it’s a question they answered. Here is the code to do just that.

<quer:projection id="idReturnField" alias="Header_Alias" xmlns:quer="http://www.taleo.com/ws/integration/query">
  <quer:query projectedClass="TransitionProcess" alias="Transition_Item_Id">
    <quer:projections>
      <quer:projection alias="Transition_Item_Id">
        <quer:decode>
          <quer:field path="ProfileInformation,Candidate,QuestionAnswers,Answer,Number"/>
          <quer:string>[AnsNo]</quer:string>
          <quer:string>YES</quer:string>
          <quer:string>[AnsNo]</quer:string>
          <quer:string>NO</quer:string>
          <quer:string>NA</quer:string>
        </quer:decode>
      </quer:projection>
    </quer:projections>
    <quer:filterings>
      <quer:filtering>
        <quer:equal>
          <quer:field path="ProfileInformation,Candidate,QuestionAnswers,Question,Code"/>
          <quer:string>[QuesCode]</quer:string>
        </quer:equal>
      </quer:filtering>
      <quer:filtering>
        <quer:equal>
          <quer:field path="Number"/>
          <quer:field ownerQuery="MainQuery" path="Number"/>
        </quer:equal>
      </quer:filtering>
    </quer:filterings>
  </quer:query>
</quer:projection>

The definitive upgrade protocol for TCC is spelled out in Doc ID 1907629.1, here’s the answer:

Read More

I’m always trying to make sense of TCC versions and found this article on MOS that addresses it SD6004 – TCC Version (Doc ID 1047569.1)

Read More

Another piece of documentation buried in the docs of a TCC installation.

As we know the [NOW] is a symbol that translates the current date and time as such:
The default date format is: NOW(“yyyyMMdd’T’HHmmss”) = 20080702T10:12:00

You can specify the time format by using any supported date and time pattern: NOW(“EEE, MMM d, yyyy”) = Wed, Jul 2, 2008

For more information on supported date and time patterns, please refer to: http:// java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html

This is strait out of the manual…

Read More

This is for new hire exports where you only want the most recent offer to be returned.  Remember to set the ownerQuery name.

<quer:filtering xmlns:quer="http://www.taleo.com/ws/integration/query">
<quer:equal>
<quer:field path="Offers"/>
<quer:query projectedClass="Offer" alias="My_Offer_Subquery">
<quer:projections>
<quer:projection alias="MaxOffer">
<quer:maximum>
<quer:field path="Offers,Number"/>
</quer:maximum>
</quer:projection>
</quer:projections>
<quer:filterings>
<quer:filtering>
<quer:equal>
<quer:field path="Application,Offers"/>
<quer:field ownerQuery="NewHire" path="Offers,Number"/>
</quer:equal>
</quer:filtering>
</quer:filterings>
</quer:query>
</quer:equal>
</quer:filtering>

You are correct, normally a record that is dropped from a net-change data file will result in it being deleted or de-activated in the zone by following net-change run.  However if there was a net-change setup run before the next ‘normal’ net-change than this wouldn’t happen.   This is because the net-change setup will delete the current net-change data repository and then re-populates it with zone values, but only for those records in the data file.  I’ve recently written an example for this scenario that may make this more clear.

Read More