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.