taleo connect middleware - · pdf filetaleo connect middleware ... an event is published to...

Taleo Connect Mid

Taleo Integration Framework Admin

S

dleware

istration Guide

oftware Version: SP4

August 2006

Taleo Integration Framework Administration Guide

Confidentiality It shall be agreed by the recipient of the document (hereafter referred to as “the other party”) that confidential information disclosed by Taleo through its documents shall be retained in confidence by the other party, and its respective employees, affiliates and/or subsidiaries, pursuant to the following terms and conditions:

For the purpose herein, the term “Confidential Information” shall mean the following:

Any information, know-how, data, process, technique, design, drawing, program, formula or test data, work in process, business plan, sales, suppliers, customer, employee, investor or business information contained in a document, whether in written, graphic, or electronic form; or

Any document, diagram, or drawing which is either conspicuously marked as “Confidential”, known or reasonably known by the other party to be confidential, or is of a proprietary nature, and is learned or disclosed in the course of discussions, demonstrations, or other collaboration undertaken between the parties.

Taleo Connect Middleware i


Table of Contents 1 About this Guide .....................................................................................................1

1.1 Additional Information ......................................................................................1 2 Integration Server and Taleo Integration Framework ...................................................2

2.1 Overview.........................................................................................................2 2.2 Framework Package descriptions .......................................................................2

2.2.1 TaleoFrameworkAutomaticTestingV1 ..........................................................3 2.2.2 TaleoFrameworkCSVImportV1 ...................................................................3 2.2.3 TaleoFrameworkCoreV1 ...........................................................................3 2.2.4 TaleoFrameworkListenersV1.......................................................................3 2.2.5 TaleoFrameworkTransformerV1 .................................................................3 2.2.6 TaleoFrameworkWsCmdProcCoreV1..........................................................3 2.2.7 TaleoFrameworkWsCmdProcV1.................................................................3 2.2.8 TaleoFrameworkWsExtractCoreV1..............................................................3 2.2.9 TaleoFrameworkWsExtractSysCoreV1 .........................................................3 2.2.10 TaleoFrameworkWsExtractSysV1 ................................................................4 2.2.11 TaleoFrameworkWsExtractV1.....................................................................4 2.2.12 TaleoFrameworkWsIsCoreV1.....................................................................4 2.2.13 TaleoFrameworkWsIsV1 ............................................................................4 2.2.14 TaleoFrameworkWsSysCoreV1...................................................................4 2.2.15 TaleoFrameworkWsSysV1..........................................................................4 2.2.16 TaleoFrameworkWsTaskCoreV1.................................................................4 2.2.17 TaleoFrameworkWsTaskDefaultImplV1 .......................................................4 2.2.18 TaleoFrameworkWsTaskSampleV1 .............................................................4 2.2.19 TaleoFrameworkWsTaskV1........................................................................4

3 Archiving ................................................................................................................5 4 Securing the Framework ...........................................................................................6

4.1 Concepts.........................................................................................................6 4.1.1 TN Security Concept .................................................................................6 4.1.2 Integration Framework Security Concept .....................................................6

4.2 Changing the default ACL configuration.............................................................7 5 Monitoring, Troubleshooting and Alerting ..................................................................9

5.1 Log Level.........................................................................................................9

Taleo Connect Middleware ii


5.2 Step Resubmittal ..............................................................................................9 5.3 Troubleshooting.............................................................................................10

6 Crash Recovery .....................................................................................................11 7 Configuring the Framework ....................................................................................12

7.1 Overview.......................................................................................................12 7.1.1 Customer Configuration..........................................................................12 7.1.2 Routing Configuration.............................................................................12 7.1.3 Application versioning and configuration files............................................13

7.2 How to deploy new configuration files ..............................................................14 7.2.1 Create the file ........................................................................................14 7.2.2 Store the file in the configuration path ......................................................14 7.2.3 Validate the XML file against the associated schema definition ....................14 7.2.4 Reload the file in Taleo Integration Framework ..........................................14

8 Taleo Framework Properties....................................................................................15 8.1 Configuration Files Properties..........................................................................15

8.1.1 watt.taleo.Framework.config.paths ...........................................................15 8.1.2 watt.taleo.Framework.routing.path ...........................................................15

8.2 Large Document Handling Properties ...............................................................15 8.2.1 watt.taleo.Framework.xml.preReadThreshold.............................................15 8.2.2 watt.taleo.Framework.repository.path .......................................................16 8.2.3 watt.taleo.Framework.ftp.tempPath...........................................................16 8.2.4 watt.taleo.Framework.mgr.displaySize ......................................................16

8.3 Debugging Properties .....................................................................................17 8.3.1 watt.taleo.Framework.showpasswords ......................................................17 8.3.2 watt.taleo.Framework.wikiURL..................................................................17 8.3.3 watt.taleo.Framework.config.listLoadedFiles ..............................................17 8.3.4 watt.taleo.Framework.pub.waitTime .........................................................18

9 Glossary ...............................................................................................................19

Taleo Connect Middleware iii


1 About this Guide This Guide explains how to manage the Taleo Integration Framework.

• It first describes the basic configuration of the Framework.

• It then documents how to deploy new customers or applications to the Framework.

• It concludes by listing monitoring and maintenance activities related to the Framework.

Before using this manual, you should be familiar with the Taleo Integration Framework User’s Guide and have have some knowledge of the Framework’s functionality.

To use this guide effectively, you should be able to edit XML files and manage a webMethods Integration Server.

1.1 Additional Information Troubleshooting Information. A complete list of errors and exceptions related to the Taleo Integration Framework in the Troubleshooting Guide is available on the Taleo Wiki.

Additional Information. All other Taleo Framework documentation is available on the Taleo Intranet Portal (TIP).

Taleo Connect Middleware 1

http://wiki/index.php?title=WM_Package_Development_-_Monitoring_and_Alerting

http://tip/C4/C3/Taleo Connect Middleware/default.aspx

http://tip/C4/C3/Taleo Connect Middleware/default.aspx


2 Integration Server and Taleo Integration Framework

2.1 Overview The Taleo Integration Framework implements a middleware layer. It contains several packages that interact with each other to process document requests and their responses, which are exchanged between Taleo applications or external systems (i.e., customer systems) or both.

Most of the Framework configuration and functionality is achieved using descriptive configuration files (i.e., XML files). This means the Framework is highly extensible once deployed in production without the need to redeploy additional IS 3.0 solution packs. This also means that the Administrator will have to plan new activities to deploy and maintain new customers or new applications in the Framework.

The Taleo Integration Framework does not use webMethods Trading Networks (TN). However, most concepts implemented by the TN (routing, document recognition, monitoring, security) were adapted to the Framework. Instead, the Framework uses the webMethods Broker and webMethods Process Run Time (PRT). For backward compatibility, documents that are not compatible or supported by the Taleo Integration Framework will still be routed to the Trading Networks.

2.2 Framework Package descriptions The following sections describe the Taleo Framework packages and their dependencies.



2.2.1 TaleoFrameworkAutomaticTestingV1 This package is used in the QA environment to run regression tests against the Taleo Framework. It is not intended to be used in production environments.

2.2.2 TaleoFrameworkCSVImportV1 This package implements the CSV import feature. It allows the Framework to receive CSV files and convert them to RS-XML requests, then to convert the associated RS-XML responses to CSV. Note that the CSV import feature only supports a standard set of entities and fields, referred to as Standard CSV Offering, as documented in the Standard CSV Import Reference on the TIP.

2.2.3 TaleoFrameworkCoreV1 This package contains the kernel of the Framework logic. It handles the configuration files, document dispatch, Framework security, and most business rules that apply to the Framework.

2.2.4 TaleoFrameworkListenersV1 This package contains webMethods triggers that are registered with the webMethods Broker. Each application type, with which the Framework interacts, is represented by one trigger and “listens” for specific events, defined by some descriptive routing configuration files. When such an event is published to the webMethods Broker, the corresponding triggers are notified and, in turn, start specific process instances.

2.2.5 TaleoFrameworkTransformerV1 This package contains the specifications and the services used in model transformation steps.

2.2.6 TaleoFrameworkWsCmdProcCoreV1 This package contains the logic for the WS-CMD-PROC model. It is registered with the model manager in the TaleoFrameworkCoreV1 package.

2.2.7 TaleoFrameworkWsCmdProcV1 This package is generated at design time by the webMethods Modeler. It is dependant on the WS-CMD-PROC model.

2.2.8 TaleoFrameworkWsExtractCoreV1 This package contains the logic for the WS-EXTRACT model. It is registered with the model manager in the TaleoFrameworkCoreV1 package.

2.2.9 TaleoFrameworkWsExtractSysCoreV1 This package contains the logic for the WS-EXTRACT-SYS model. It is registered with the model manager in the TaleoFrameworkCoreV1 package.


http://intranet.taleo.tc/C4/C3/Taleo Connect Middleware/Document Library/TaleoConnectMiddleware_StandardCSVImport(v1.0)_Professional(v610_700).pdf

http://intranet.taleo.tc/C4/C3/Taleo Connect Middleware/Document Library/TaleoConnectMiddleware_StandardCSVImport(v1.0)_Professional(v610_700).pdf


2.2.10 TaleoFrameworkWsExtractSysV1 This package is generated at design time by the webMethods Modeler. It is dependant on the WS-EXTRACT-SYS model.

2.2.11 TaleoFrameworkWsExtractV1 This package is generated at design time by the webMethods Modeler. It is dependant on the WS-EXTRACT model.

2.2.12 TaleoFrameworkWsIsCoreV1 This package contains the logic for the WS-IS model. It is registered with the model manager in the TaleoFrameworkCoreV1 package.

2.2.13 TaleoFrameworkWsIsV1 This package is generated at design time by the webMethods Modeler. It is dependant on the WS-IS model.

2.2.14 TaleoFrameworkWsSysCoreV1 This package contains the logic for the WS-SYS model. It is registered with the model manager in the TaleoFrameworkCoreV1 package.

2.2.15 TaleoFrameworkWsSysV1 This package is generated at design time by the webMethods Modeler. It is dependant on the WS- SYS model.

2.2.16 TaleoFrameworkWsTaskCoreV1 This package contains the logic for the WS-TASK model. It is registered with the model manager in the TaleoFrameworkCoreV1 package.

2.2.17 TaleoFrameworkWsTaskDefaultImplV1 This package contains a default module implementation managed by the WS-TASK model. It converts an Onboarding specific document into an HR-XML document and routes it to the customer.

2.2.18 TaleoFrameworkWsTaskSampleV1 This package contains a list of standard implementations managed by the WS-TASK model. It is used for QA purposes only and should not be deployed in production environments.

2.2.19 TaleoFrameworkWsTaskV1 This package is generated at design time by the webMethods Modeler. It is dependant on the WS-TASK model.



3 Archiving The Taleo Framework involves many IO activities on the Integration Server that can be divided in two parts:

• The IO on the file system. Each file or document content that the user wants to monitor from the WmMonitor application is written on the file system to the path specified by the watt.taleo.Framework.repository.path TIF property.

• The IO on the database. Each model used by the Framework generates a lot of data in the ProcessAudit and ISCoreAudit schemas, configured on the Integration Server under the Settings/JDBC Pool section. This data is generated and maintained by the WmPRT and WmMonitor components of the IS. The Framework does not write or access this data directly.

Running a lot of transactions on the Integration Server progressively loads the database and file system, and may reduce server resources and performance. To prevent this, the IO generated by the Integration Framework is archived at regular intervals. This archiving is part of the IS 3.0 global Archiving Solution. You can customize the archive settings by editing the configuration file stored under $IntegrationServer/packages/TaleoPublicUtilV1/settings.xml. By default, data is deleted after 31 days.

The archiving task runs everyday at 4:00 a.m. It archives the processing data and the files stored in the Taleo Framework Repository as well as TN data, services data, activation data, server data. and Broker documents when configtured to be logged.

Taleo Framework Repository archiving was added to the IS 3.0 Archiving Solution in SP3.



4 Securing the Framework

4.1 Concepts

4.1.1 TN Security Concept The TN architecture implements different levels of security to ensure only authenticated and trusted persons are allowed to send documents.

1. The first level of security authenticates the user. The user must be logged in to the Integration Server.

2. The second level of security checks the user login against the ACL; to access TN services, the user must be on the TNPartners ACL.

3. The third level of security compares the logged username with the SenderID extracted from the incoming document. If the logged user is not on the TNAdministrators ACL, the SenderID and the login username must match.

4. The fourth level of security checks that the TN Profile corresponding to the SenderID is valid and enabled. The document is rejected otherwise.

5. The fifth level of security is configured by the TN processing rules. Once the incoming document type is recognized, the TN searches for a processing rule that matches the extracted SenderID as allowed SenderIDs and the extracted ReceiverID as allowed ReceiverIDs. If no matching rule is found, the default rule applies, which usually ignores the document or returns an error to the sender.

4.1.2 Integration Framework Security Concept The Taleo Integration Framework (TIF) implements the same levels of security but differently.



Gro

ups

1. The first level of security authenticates the user. The user must be logged in to the Integration Server.

2. The second level of security checks the user login against the ACL; to access TIF services, the user must be part of the ISFrameworkUsers ACL. If the document sent to the gateway service (/taleo.is.Framework.core.v1.handler/receive) is not supported by the TIF, it is routed to the TN. In this case, the user must be part of the ISFrameworkUsers ACL and the TNPartners ACL.

3. The third level of security compares the logged username with the SenderID extracted from the incoming document or explicitly specified to the gateway service. If the logged user is on the ISFrameworkUsers ACL and not on the ISFrameworkAdministrators ACL, the SenderID and the username must be part of the same partner (that is, referenced in the same Taleo Framework configuration file).

4. The fourth level of security validates that the delivery methods corresponding to the SenderID and ReceiverID do both exist. If this check fails, an error is returned to the sender. Additionally, if the user accesses the gateway service using an HTTP/S client, an HTTP 500 error code is returned to the client.

5. The fifth level of security validates that the delivery methods corresponding to the SenderID and ReceiverID are both part of the same partner (that is, referenced in the same Taleo Framework configuration file). If this check fails, an error is returned to the sender. Additionally, if the user accesses the gateway service using an HTTP/S client, an HTTP 500 error code is returned to the client.

The Integration Framework security rules only apply if the document is managed by the Framework. If the document is routed to the TN (not managed by the Framework and not invoked by a web-service), the TN security rules apply. If the document is invoked by a web-service (SOAP request to a web-service hosted on the Integration Server), the security is enforced by the web-service itself and not enforced by the gateway service.

4.2 Changing the default ACL configuration By default the ACLs are defined as follows:



• All IS authenticated users (except the Anonymous ones) and all Framework users who are part of the ISFrameworkUsers group are automatically on the ISFrameworkUsers ACL.

• All IS administrator users who are part of the Administrators group and all Framework administrators who are part of the ISFrameworkAdministrators group are automatically on the ISFrameworkAdministrators ACL.

This was implemented in a way to minimize the security management overhead to the IS administrator. However, the IS administrator may want to restrict the users who are allowed to access services and resources protected by the ISFrameworkUsers or ISFrameworkAdministrators ACLs.

For example, the IS Administrators may want to limit the access to these resources only to users who are part of the ISFrameworkUsers and ISFrameworkAdministrators groups. Users that still use the TN (for documents not yet supported by the TN) also need to be part of the TNPartners group in order to access TN services protected by the TNPartners ACL.

To implement this,

1. Login to the Administrator page. Select Security/ACLs.

2. In the Select ACL list, select the ISFrameworkUsers ACL.

3. Add the TNPartners, TNAdministrators and ISFrameworkAdministrators groups.

4. Remove the Everybody group.

5. In the Select ACL list, select the ISFrameworkAdministrators ACL.

6. Remove the Administrators group.

Note: After these changes, if you want a user to be able to use the Taleo Framework, you have to add him manually the ISFrameworkUsers group. Similarly, if you want a user to be able to use the Taleo Framework with administrative authority, you have to add him manually to the ISFrameworkAdministrators group.



5 Monitoring, Troubleshooting and Alerting Since the Taleo Framework does not use the webMethods Trading Networks, the TN Console cannot be used to monitor or troubleshoot communication and other problems.

Instead, you can use the webMethods Monitor tool that gives you have access to documents logged by the webMethods Broker, to audited services logging, and to process transactions. The graphical interface allows resubmitting steps at different places in the model workflow and monitoring not only documents but also entire transactions.

5.1 Log Level Each model instance logs one to many activity log entries. The amount of log entries depends directly on the IS Server Log settings. The higher the level of logging, the larger the activity logs will be. To change the level of logging of the IS:

1. Login to the IS Admistrator Page. Select Settings/Logging.

2. Click “Edit Logging Settings”.

3. Select the Level of Logging from the list. A recommended value for a production environment is 3 (I–Information). To increase the amount of activity logs, set the level higher. The deepest logging level used by the Taleo Framework is 7 (V3–Verbose3); however, this level of logging is not recommended for a production environment.

Each log entry is formatted using a specific pattern that identifies from which level this event will be logged. For instance, an activity log that starts with “[TIF.0000.0000V1]” indicates that this message only appears if the log level is “V1”, that is 5 (V1–Verbose1) and higher. The exact pattern is documented in the Taleo Integration Framework User’s Guide.

5.2 Step Resubmittal The webMethods Monitor provides resubmittal functionality for services and processes. The following are resubmittal limitations in Taleo Framework processes (models):

1. By design, only certain steps can resubmit the transaction. Other steps may not support the resubmittal because, for example, this may affect the transaction data.

2. When multiple steps support resubmittal in a model, carefully decide which step to resubmit, especially when resubmitting steps that interact with external systems. For example, if a step delivered a document to an external system that already returned a valid response, and a step failed downstream in the process, do not resubmit from the deliver step, but rather from the response reception step. This avoids resubmitting a document already successfully processed by the external system. It is not that critical for extraction requests, but for writing requests that may modify data in the external system this may be a critical aspect to consider.

3. Some models have complex logic related to the resubmittal feature. For example, the WS-CMD-PROC has a timeout management that affects the resubmittal feature. The impact is documented online in the model (model and step documentation available through the webMethods Monitor) and mostly in the Taleo Integration Framework User’s Guide.



5.3 Troubleshooting You can troubleshoot problems that occur while running Taleo Framework transactions in several ways:

1. If the document reaches a model instance, monitor the instance from WmMonitor.

2. If the document does not reach the model instance (i.e., no response received), but does reach the Taleo Framework Repository, you can monitor it from there. To do so, login to the Taleo Framework Web Manager and select Analysis/Transactions. For more information on searching for documents in the repository, see the Taleo Integration Framework User’s Guide.

3. If the document does not reach the model or the repository, you can investigate for errors or warnings in the IS Server Log.

4. If you experience connectivity problems with the webMethods Broker, you can investigate the number of documents pending delivery to the models with WmBrokerAdmin. You need advanced webMethods Broker knowledge to troubleshoot the Broker itself.

5. Errors thrown by the Taleo Framework services are monitored and logged in the ProcessAudit database and retrieved by the OVO implementation agent, which is part of IS 3.0. For more information concerning alerting in the Taleo Framework, see the Taleo Integration Framework User’s Guide.

You can troubleshoot errors logged in the IS Server Log and the webMethods Monitor, or those reported by the OVO Agent, using the Taleo Integration Framework Troubleshooting Guide.

For more information on how to use the webMethods Monitor tool, or the Troubleshooting and Alerting functionality available to Taleo Framework users, see the Taleo Integration Framework User’s Guide.



6 Crash Recovery Normally, no action is necessary after an Integration Server or webMethods Broker crash. Documents that were queued in the webMethods Broker will be delivered by the Broker once the IS has been restarted. If the Broker crashes, and not the IS, the sender receives errors indicating that no model acknowledged the document processing. Instances in progress will either fail or timeout and be completed with errors. These errors are reported to the OVO agent so Administrators can take action (i.e., restart the server or the Broker or resubmit failed or timed out webMethods Monitor transactions).

However, if the Integration Server crashes or planned system maintenance requires the IS to restart, manual intervention is required; the model instances in a waiting step (you can monitor this from the webMethods Monitor tool) will not be recovered automatically from an IS restart. NullPointerException exceptions will be thrown by the PRT that can be monitored in the Server and Error Logs while rebooting the IS.

The instances that were in a waiting step will not complete or timeout but keep hanging. You will have to manually stop these transactions. Then resubmit them from the start step. The webMethods Professional Services team investigated this and concluded that this behavior was “expected” by the webMethods PRT. Consider it as a known limitation.



7 Configuring the Framework You perform most of Taleo Framework configuration tasks by maintaining descriptive XML files. The following sections describe the format and purpose of these XML files, and propose some Integration “templates” to illustrate how to use them.

7.1 Overview There are two types of configuration files: Customer and Routing.

7.1.1 Customer Configuration Customer configuration files contain connectivity, cryptographic, and versioning information specific to each customer. They are similar to Trading Networks Profiles, with the following differences:

• As opposed to TN Profiles, they contain both delivery methods (to deliver data to) and retrieval methods (to retrieve data from).

• Whereas TN Profiles store multiple profiles associated to the same customer separately, customer configuration files store them by partner (one configuration file per partner only).

• Cryptographic settings are stored by partner or customer not independently by delivery method.

• Customer configuration files define a list of pre-configured integration scenarios that can be scheduled in the Framework using the Taleo Integration Framework Web Manager.

For a detailed description of the customer configuration files, see the Taleo Integration Framework Customer Configuration Reference Guide.

7.1.2 Routing Configuration Routing configuration files are similar to Trading Networks processing rules, with the following differences:

• A model instance is started instead of a TN service execution.

• The model instance is triggered by a Broker event instead of a TN document.

Integration is all about connecting systems that may host different types of applications. Each routing configuration file is associated to one application type only (i.e., Taleo Onboarding, Taleo Professional, Taleo Contingent, Customer Systems, etc.). The content of the routing configuration file defines which models should be triggered under which circumstances (i.e., Broker event, system versions).

Each application type registers as a “listener” for specific integration events. In the context of the Taleo Integration Framework, an event is the signal to start a specific integration process.

The integration process that should be started is defined in the routing configuration file. It may depend on the source application type (that published the event to the Broker) or on its version, or on the listener application type or on its version. The combination of the source



and target application type, the listened event, the model type to start and the additional parameters to be submitted to the model is a called a route in the Taleo Integration Framework.

For a detailed description on routing configuration files, see the Taleo Integration Framework Routing Configuration Reference Guide.

7.1.3 Application versioning and configuration files The Integration Framework transforms documents from one format to another within the Middleware layer. This implies knowing the exact format of the source system (the one sending the transformation document) and of the target system (the one consuming the transformed document).

Some transformations are generic in that the version of the source or target system may not affect the way the documents are transformed. However, especially concerning transformations using T-SOAP format, the version of the source or target application may affect the transformation.

Source application version Most of these transformations are executed using XSL files. To transform documents, XSL files refer to XML elements that belong to specific namespaces. The namespace can be used to version the XML format. If the namespace in the source document does not match that in the XSL file (because of a different version than the one the XSL is expecting), the transformation will fail to produce the expected output.

To transform a document request properly, the Integration Framework needs to know which version the source application is currently using.

Target application version Some T-SOAP documents can only be consumed by a specific version of a target application. For example, if you try to send a data synchronization request (part of the Professional to Onboarding OLF synchronization) to a Professional application that is not 7.0 or higher, the request will fail because earlier Professional versions cannot consume this document format.

To transform a document request, the Integration Framework needs to know the version of the target application in use.

Configure the application versions Each route in the routing configuration file applies to a specific source and target application version.

The source and target application versions in use for a specific customer are indicated in the customer configuration file. Each delivery method is associated to a specific application type and version.

The Framework Administrator is responsible for synchronizing the version of each delivery method with the actual version of the application to which the delivery method points.



Taleo application migration When a Taleo application migration for a customer is planned, the Framework Administrator must be notified of the migration and update the version of the associated delivery method in the customer configuration file.

7.2 How to deploy new configuration files

7.2.1 Create the file For a schema reference of the configuration files, see the Taleo Integration Framework Customer Configuration Reference Guide and the Taleo Integration Framework Routing Configuration Reference Guide.

For concrete examples of configuration files, see the Taleo Integration Framework Standard Use Cases and the Taleo Integration Framework Custom Use Cases.

7.2.2 Store the file in the configuration path Store customer configuration files in the path specified by the watt.taleo.Framework.config.paths Framework property.

Store routing configuration files in the path specified by the watt.taleo.Framework.routing.path Framework property.

7.2.3 Validate the XML file against the associated schema definition Use an XML client (XMLSpy, Oxygen, or your favorite XML editor) to validate the XML configuration file against the associated schema definition:

• For customer configuration files, the schema is configuration.xsd

• For routing configuration files, the schema is RoutingConfiguration.xsd

7.2.4 Reload the file in Taleo Integration Framework To (re)load a validated customer configuration file,

1. Login to the Taleo Framework Web Manager and choose Manager/Configuration.

2. Click on the “Reload Configuration Files” link.

3. A message confirms the customer configuration file has been reloaded.

To (re)load a validated routing configuration file,

1. Login to the IS Administration Page and choose Packages/Management.

2. Reload the TaleoFrameworkListenersV1 package.

3. Ensure that the package reloads without throwing an error in the IS Server or Error Logs.

If an error is thrown while reloading the file, repeat steps from sections 7.2.3 and 7.2.4 until the file successfully (re)loads in the Taleo Framework.



8 Taleo Framework Properties The following section lists and describes the Taleo Framework configuration properties. These properties are set with the Taleo Framework Web Manager.

For more information about accessing the Taleo Framework Properties, see the Taleo Integration Framework User’s Guide.

8.1 Configuration Files Properties

8.1.1 watt.taleo.Framework.config.paths

Description The absolute directory paths of the hard drive where customer configuration files are stored. To set this property, specify a comma-separated list of all the paths where you want the Taleo Framework to load the customer configuration files. Specify absolute directory paths to directories on the same computer as the Integration Server.

Default Value JVM’s user directory (i.e., the value of java.user.home).

Example To load the customer configuration files from the /home/wmethods/isFramework/config path, specify watt.taleo.Framework.config.paths = /home/wmethods/isFramework/config

8.1.2 watt.taleo.Framework.routing.path

Description The absolute directory path of the hard drive where routing configuration files are stored. Specify the absolute directory path to a directory on the same computer as the Integration Server.

Default Value The config directory of the TaleoFrameworkListenersV1 package (i.e., /opt/wm/IntegrationServer/packages/TaleoFrameworkListenersV1/config).

Example To load the routing configuration files from the /home/wmethods/isFramework/routing path, specify watt.taleo.Framework.routing.paths = /home/wmethods/isFramework/routing

8.2 Large Document Handling Properties

8.2.1 watt.taleo.Framework.xml.preReadThreshold

Description Determines the maximum number of bytes that the Taleo Framework reads into memory from the start of an XML document in order to extract routing information (i.e., SenderID, ReceiverID).



Specify a positive whole number.

Default Value 20480

Example watt.taleo.Framework.xml.preReadThreshold = 20480

8.2.2 watt.taleo.Framework.repository.path

Description The absolute directory path of the hard drive where the Taleo Framework temporarily stores large documents rather than keeping them in memory. Specify the absolute directory path to a directory on the same computer as the Integration Server.

Default Value JVM’s user directory (i.e., the value of java.user.home).

Example To load the customer configuration files from the /home/wmethods/isFramework/repository path, specify the following value watt.taleo.Framework.config.paths = /home/wmethods/isFramework/repostitory

8.2.3 watt.taleo.Framework.ftp.tempPath

Description The absolute directory path of the hard drive where the Taleo Framework writes files it polls from an external location, while processing a Taleo command. The files are deleted once the command processing is completed. Specify the absolute directory path to a directory on the same computer as the Integration Server.

Default Value JVM’s temporary directory (i.e., the value of java.io.tmpdir).

Example To store the temporary files in the /home/wmethods/isFramework/ftpTemp directory, specify watt.taleo.Framework.ftp.tempPath = /home/wmethods/isFramework/ftpTemp

8.2.4 watt.taleo.Framework.mgr.displaySize

Description The maximum number of bytes displayed when viewing documents from the Taleo Framework Web Manager. If the document is larger than the specified number of bytes, use the navigation buttons to scroll down (“>>”) and up (“<<”).

This property is useful for large documents (of several MB or GB) because it accesses small chunks of the content rather than loads the entire document in memory.



Specify a positive whole number.

Default Value 5000

Example To load the first 5,242,880 bytes (5 MB) of a document, specify watt.taleo.Framework.mgr.displaySize = 5242880

8.3 Debugging Properties

8.3.1 watt.taleo.Framework.showpasswords

Description Flag to indicate whether passwords should be displayed in the Taleo Framework, especially when retrieving and delivering documents.

Default Value false

Example To show passwords when retrieving or delivering documents, set watt.taleo.Framework.showpasswords = true

8.3.2 watt.taleo.Framework.wikiURL

Description The absolute URL to the Wiki page containing the Taleo Integration Framework Troubleshooting Guide. When the property value is not empty, each activity log code is formatted to link to this URL and should point to diagnostic and troubleshooting hints corresponding to the error or warning code. When empty, the feature is disabled.

Default Value empty

Example To link the Troubleshooting Guide to http://wiki/title=IS3-TG, specify watt.taleo.Framework.wikiURL = http://wiki/title=IS3-TG

8.3.3 watt.taleo.Framework.config.listLoadedFiles

Description Flag to indicate whether reloading customer configuration files should show the list of currently loaded files. If set to false, only files (re)loaded or unloaded are displayed. If set to true, already loaded files are also displayed.

Default Value false

Example To display the list of already loaded files while reloading customer configuration files, specify watt.taleo.Framework.config.listLoadedFiles = true



8.3.4 watt.taleo.Framework.pub.waitTime

Description The time, in milliseconds, the Taleo Framework Dispatcher should wait for a model to acknowledge the reception of a published document. The acknowledgment of a document means that a model was started. If no acknowledgment is received, then no model was started and a configuration problem may exist. The time needed for a model to start may depend on the load of the Integration Server.

Default Value 300000

Example To wait 180000 milliseconds (3 minutes) before considering an acknowledgment timeout, specify watt.taleo.Framework.pub.waitTime = 180000



9 Glossary

Message Exchange Pattern (MEP)

As defined by the W3C SOAP recommendation, a Message Exchange Pattern (MEP) is a template that establishes a pattern for the exchange of messages between SOAP nodes. MEPs are a type of feature, and unless otherwise stated, references in the W3C specification to the term "feature" apply also to MEPs. The request-response MEP specified in SOAP 1.2 Part 2 [SOAP Part 2] illustrates the specification of a MEP feature.

W3C

W3C is an acronym for World Wide Web Consortium.

SOAP

Simple Object Access Protocol (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. SOAP is a recommendation of the W3C. The "Part 1: Messaging Framework" of the recommendation defines, using XML technologies, an extensible messaging Framework containing a message construct that can be exchanged over a variety of underlying protocols.

SOAP 1.2 is the latest version of the protocol that replaces the previous SOAP 1.1. The Taleo Framework supports both versions.

XSL

XSL (eXtensible Style Language) is a language for expressing stylesheets which may be used to transform XML documents into other formats or to display XML documents in XML-capable browsers.

XSLT

XSLT (XSL Transformations) is a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting. XSL specifies the styling of an XML document by using XSLT to describe how the document is transformed into another XML document that uses the formatting vocabulary. XSLT is also designed to be used independently of XSL. However, XSLT is not intended as a completely general-purpose XML transformation language. Rather it is designed primarily for the kinds of transformations that are needed when XSLT is used as part of XSL

Taleo Integration Framework (Taleo Framework)


http://www.w3.org/

http://www.w3.org/TR/soap12/

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/


Integration Server 3.0 Taleo Framework (Taleo Framework) is a set of generic infrastructure components that can be used to implement various integration businesses uses cases.

The objective is to normalize the integration platform by grouping common businesses uses cases using standard and generic business process models. Customization needs are isolated in specific business steps of business process models.

CSV (comma-separated values)

CSV (comma-separated values) is a file format used as a portable representation of a database. Each line is one entry or record; the fields in the record are separated by commas. This format is often used to import data into spreadsheet software.

Generic CSV format

This is a proprietary Taleo CSV format.

Selection Query

This is a proprietary Taleo syntax equivalent to the SQL syntax.

SQ-XML

This is a proprietary Taleo format to describe Selection Queries.

RS-XML

This is the old proprietary Taleo XML format used in the Taleo Professional applications v6.1.0 and older for data integration.

T-SOAP

This is the newest Taleo XML format, based on the SOAP recommendation, used in the Taleo Staffing applications v6.1.0 (and higher versions) as well as in other Taleo applications (OnBoarding, Contingent, etc…) for data integration.
