Appendix

Web Service Limits

The following web service limits apply to all web services by default.

Since	Default Value	Comment	Behavior
7.5 SP2	20	The maximum number of integration threads allowed by JVM.	The Web Service policy manager ensures that no more than x web service calls runs simultaneously. When the maximum number of running web service call is reached, any new web service call will be rejected with an error message.
7.5 SP2	-1 (no minimum)	The minimum export rate that is tolerated by the integration toolkit. This setting enables the integration toolkit to stop the processing of an export if the current data export rate is too low. The data export rate indicates the number of entities exported in an hour.	When serializing export results (after each entity or after each CSV report row), check the export rate. If the export rate is lower than the allowed export rate, the export is cancelled.
7.5 SP2	200	The maximum number of records that can be returned by an export request sent to the integration export service. If a request would return more results, an error is returned instead.	The maximum number of records is check before serializing results.
7.5 SP2	2048000 (2 MB)	The maximum size (in bytes) of the response generated by an export request sent to the integration export service. If the service notices that the response size is larger than this value, an error is returned instead.	When serializing export results (after each entity or after each CSV report row), check the export size. If export size is greater than the allowed size, the export is cancelled.
7.5 SP2	90 (1 minute 30 sec)	The maximum time in seconds permitted for an export request. This setting enables the integration toolkit to stop an export request if it takes more than the specified amount of time.	When serializing export results (after each entity or after each CSV report row), check the elapsed time of the export. If the elapsed time is greater than the maximum export time, the export is cancelled.
7.5 SP2	25000 Corresponds to an average of 17 calls/minute	The maximum number of web service calls that can be invoked daily.	The maximum is checked before invoking the service. If the daily invocation maximum is already reached, the service is not invoked and an error is returned to the user.
7.5 SP2	250000 Corresponds to an average of 10 exported entities/call for 17 calls/minute (more/call if less calls/minute)	The maximum number of records that can be exported daily.	The maximum is checked before extracting data. E.g.: If the limit is 250 000 records per day and there is already 200 000 exported records for the current day, an extract returning 50 001 records will not run because this would exceed the daily limit.
Always	N/A	Certain WSDLs may contain two types where the only difference in their names is that one is all in small-case letters and the other contains upper-case letters. This peculiarity is a limiting factor for the Visual Basic language as it is not case sensitive.	When a customer tries to use this type of WSDL to generate a stub in Visual Basic, the generated class will not compile since two different classes will have the same name.

Version 7.5 Namespace Limitations

You must be aware of the following limitations generated by the way that the namespaces are used in Version 7.5 WSDLs. (Note that these limitations have been fixed in Taleo 10 SP1 and later).

Normally, in Java, these limitations can be worked around by assigning the different usages of a namespace to different packages and then eliminate any possible collision in the Java code. But with the XML Bean data binding, this solution is not possible. Here is an extract from the XML Bean documentation:

"Note: XMLBeans doesn't support using two or more sets of java classes (in different packages) mapped to schema types/elements that have the same names and target namespaces, using all in the same class loader. Depending on the direction you are using for the java classes to schema types mapping, some features might not work correctly. This is because even though the package names for the java classes are different, the schema location for the schema metadata (.xsb files) is the same and contains the corresponding implementing java class, so the JVM will always pick up the first on the classpath. This can be avoided if multiple class loaders are used."

Here is a list of know limitations that are caused by this XML Bean limitation:

Namespace Usage Case #1

The same integration toolkit namespace is used for two different contents.

The import services are using the integration toolkit namespace to specify a different content that the export ones.

Known Limitation

The impact is that it might not be possible to use an import service and an export service in the same java program.

Namespace Usage Case #2

The import service parameters definitions are put in the data model namespace.

For example, the Department service create operation takes a tns:createRequest message in parameter that points to a create element defined in the data model:

<wsdl:message name="createRequest">
   <wsdl:part name="parameters" element="tns:create"/>
</wsdl:message>

In the data model, it points to a Department entity.

<xsd:element name="create">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="department" type="tns:Department"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

And if we take the same example but with the Position service:

The Position service create operation takes a tns:createRequest message in parameter that points to a create element defined in the data model:

<wsdl:message name="createRequest">
   <wsdl:part name="parameters" element="tns:create"/>
</wsdl:message>

In the data model, it points to a Position entity.

<xsd:element name="create">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="position" type="tns:Position"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Known Limitation

The impact is that it might not be possible to use two different import services in the same java program.

Namespace Usage Case #3

The export service parameters definitions are put in the integration toolkit namespace.

For example, in the FindService, the findPartialEntities operation response is a findPartialEntitiesResponse element that points to a findPartialEntitiesResponse element defined in the integration toolkit namespace:

<wsdl:message name="findPartialEntitiesResponse">
   <wsdl:part name="parameters"
              element="tns:findPartialEntitiesResponse"/>
</wsdl:message>

This element points to the Entities one that is also define in the integration toolkit namespace:

<xsd:element name="findPartialEntitiesResponse">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element maxOccurs="1" minOccurs="1" name="Entities" 
                      nillable="true" type="tns:Entities"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>

And finally the Entities element points to the Entity element define in the data model:

<xsd:complexType name="Entities">
   <xsd:sequence>
      <xsd:element maxOccurs="unbounded" minOccurs="0" ref="ns1:Entity"/>
  </xsd:sequence>
</xsd:complexType>

Known Limitation

The impact is that it is not possible to use the FindService with two different data model in the same Java program because the Entities element defined in the ITK point to a Entity element that is defined in the data model namespace. Since the Entity element can be defined in multiple data model, the Java program will not be able to determine which one to use.

This will be the case when a find must be done in the art product and another one in the SmartOrg product.

Another case is when a FindService is use to search in two different version of the same product. An example of this is a search done in SmartOrg 7.5 and then done in SmartOrg 10.

Namespace Usage Case #4

The data model define in an import service is different than the one define in an export service but they are both using the same namespace.

Therefore the definition of an entity for an import service might be different that the one for an export service. For example, the definition of a candidate entity in import is different than the one in an export.

Known Limitation

In Java, it is not possible to cast the find service result to the correct object if the import service is imported before the export one.

Export Query Performance Throttles

The following export query performance throttles apply to the EXPORT web service only.

Since	Default Value	Comment	Behavior
7.5 SP2	5	The maximum depth of relations that can be specified in an export query (max.relation.deepness)	All performance throttles are checked before extracting the data.
7.5 SP2	-1	The maximum number of relations that can be specified in an export query (max.relation.count)
7.5 SP2	1	The maximum number of subqueries that can be specified in an export query (max.subquery.count)
7.5 SP2	5	The maximum number of fields that can be specified to filter an export query (max.filtering.field.count)
7.5 SP2	5	The maximum number of fields that can be specified to group fields in an export query (max.grouping.field.count) A grouping field represents a value used to group query results. In SQL, it will be pushed into the GROUP BY clause.
7.5 SP2	5	The maximum number of fields that can be specified to join other queries in an export query (max.jointing.field.count) A joint field represents a filter used to join a parent and a sub-query. In SQL, the filter will be pushed into the WHERE clause of the parent query.
7.5 SP2	1	The maximum number of levels for sub-queries that can be specified in an export query (max.subquery.level.count).
7.5 SP2	100	The maximum number of fields that can be projected in an export query (max.projection.field.count) A projection field represents a value returned by a query. In SQL, it will be pushed into the SELECT clause.

Compatibility

Taleo Connect Client compatibility with Taleo products is guaranteed one version up, when the same reference model is used. When the reference model used to create an integration point changes, compatibility is not guaranteed.

Architecture

Taleo Connect Client (TCC) communicates with Taleo Connect Server (TCS) that is embedded in every Taleo product. TCS uses internal reference models that describe each Taleo product entity available for integration. The reference models are related to the version of the business engine; the business engine contains sets of business rules that integration must follow. The reference models are not automatically compatible with each other. Taleo products are enhanced and modified from one version to the next. The business rules change to comply with the enhancements and modifications.

For information on the integration reference model changes for each release, refer to the following Notes.

See: Taleo Enterprise - Taleo Integration Release Notes (MOS under Release Notes, Maintenance Packs, Express Packs, and Incidents Resolved History)

Example

An integration point built with reference model 11 X for a version 11.X product will continue to function after the product is upgraded to version 12 X, as long as the reference model remains unchanged. In this case, compatibility is guaranteed.

Product and model compatibility

Image showing an example of a product and model compatiblity. In the example, an integration point built with reference model 11 X for a version 11.X product will continue to function after the product is upgraded to version 12 X, as long as the reference model remains unchanged. In this case, compatibility is guaranteed.

If the reference model is modified, to take advantage of a new field for example, then compatibility is not guaranteed. In this case, the integration points must be re-tested and modified if necessary. A modification to a business rule may affect integration in a minimal way. Testing is required.

Note: Integrations built using the 7.5 reference model are expected to cease to be formally supported mid to late 2014, though formal communication will be made 12 months in advance of full compatibility support stopping. It is recommended in preparation to upgrade integration scripts currently on 7.5 to the latest data model version appropriate for your zone’s version or at least begin the planning activities associated with this upgrade, subsequent testing and deployment.

The Recruiting/Professional and SmartOrg models have changed considerably from 7.5 upwards and it is recommended referencing the following guides for further information.

See: Taleo Integration Migration Guide (MOS under Release Notes, Maintenance Packs, Express Packs, and Incidents Resolved History)
See: Product Data dictionaries (MOS under Release Notes, Maintenance Packs, Express Packs, and Incidents Resolved History)