taleo integration framework

Taleo Integration Framework

User's Guide

Version 3.0 SP4

Integration Development

Revision History

Date Revision Description

01.01.2006 1.0 Initial draft

02.26.2006 2.0 SP4 final draft

03.15.2006 2.1 Edited final draft

08.30.2006 2.2 Removed reference to the Taleo Integration Framework Concept Guide

Taleo Integration Framework Version 3.0 SP4 User's Guide Revision 2.2

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

1.1 Document Conventions ...................................................................................................... 6 1.2 Additional Information......................................................................................................... 6

2 Integration Server and Taleo Integration Framework ......................................... 7 2.1 Overview............................................................................................................................. 7 2.2 Configuring the Framework ................................................................................................ 8

3 Working with the Framework Web Manager ........................................................ 9 3.1 Web Manager Overview ..................................................................................................... 9 3.2 Getting Started with the Web Manager .............................................................................. 9

3.2.1 How to Access Web Manager ............................................................................... 9 3.2.2 Logging into the Web Manager ........................................................................... 12 3.2.3 The Web Manager Page ..................................................................................... 14

3.3 What You Can Configure with Web Manager .................................................................. 15 3.3.1 The Contents Frame............................................................................................ 15 3.3.2 The Scheduler Page............................................................................................ 15 3.3.3 The Configuration Page....................................................................................... 21 3.3.4 Document Submission Page ............................................................................... 22 3.3.5 Transactions Page............................................................................................... 24

3.4 Configuring Web Manager................................................................................................ 25 3.4.1 Configuring and Web Manager User Authority.................................................... 25 3.4.2 About the Taleo Framework Properties Page ..................................................... 26

4 Working with the Business Process Models of the Framework ...................... 27 4.1 Definitions ......................................................................................................................... 27

4.1.1 What is a Business Process................................................................................ 27 4.1.2 What is a Business Process Model ..................................................................... 27 4.1.3 Taleo Framework Business Process Models ...................................................... 28

4.2 WS-IS – Standard Data Integration.................................................................................. 29 4.2.1 Model definition ................................................................................................... 29 4.2.2 Step definition...................................................................................................... 30 4.2.3 When to use this model ....................................................................................... 31 4.2.4 Business Use Cases ........................................................................................... 31 4.2.5 Built-in scenarios ................................................................................................. 32 4.2.6 Handling new scenarios ...................................................................................... 32

4.3 WS-EXTRACT – Data Extraction or Data Transformation............................................... 34 4.3.1 Model definition ................................................................................................... 34

Confidential Taleo, 2006 of 97 Taleo Integration Server 3.0 Framework User's Guide [SP4]_2.2.doc Last saved: 8/30/2006


4.3.2 Step definitions .................................................................................................... 35 4.3.3 When to use this model ....................................................................................... 37 4.3.4 Business Use Cases ........................................................................................... 37 4.3.5 Built-in scenarios ................................................................................................. 38 4.3.6 Handling new scenarios ...................................................................................... 40

4.4 WS-SYS – Transform and Forget .................................................................................... 40 4.4.1 Model definition ................................................................................................... 40 4.4.2 Step definitions .................................................................................................... 41 4.4.3 When to use this model ....................................................................................... 43 4.4.4 Business Use Cases ........................................................................................... 43 4.4.5 Built-in scenarios ................................................................................................. 43 4.4.6 Handling new scenarios ...................................................................................... 44

4.5 WS-EXTRACT-SYS – System to System Synchronization ............................................. 45 4.5.1 Model definition ................................................................................................... 45 4.5.2 Step definitions .................................................................................................... 46 4.5.3 When to use this model ....................................................................................... 48 4.5.4 Business Use Cases ........................................................................................... 48 4.5.5 Built-in scenarios ................................................................................................. 48 4.5.6 Handling new scenarios ...................................................................................... 49

4.6 WS-TASK – Task Processing........................................................................................... 50 4.6.1 Model definition ................................................................................................... 50 4.6.2 Step definitions .................................................................................................... 51 4.6.3 When to use this model ....................................................................................... 53 4.6.4 Business Use Cases ........................................................................................... 53 4.6.5 Built-in scenarios ................................................................................................. 54 4.6.6 Handling new scenarios ...................................................................................... 54

4.7 WS-CMD-PROC – Command Processing ....................................................................... 60 4.7.1 Model definition ................................................................................................... 60 4.7.2 Step definitions .................................................................................................... 61 4.7.3 When to use this model ....................................................................................... 64 4.7.4 Business Use Cases ........................................................................................... 64 4.7.5 Built-in scenarios ................................................................................................. 64 4.7.6 Handling new scenarios ...................................................................................... 64

5 Planning a new Integration Process ................................................................... 66 5.1 Identify your Needs........................................................................................................... 66 5.2 Code your Custom Transformations (optional) ................................................................ 68

5.2.1 Built-in Transformation Services Reference........................................................ 70



Built-in Custom Transformation Services Reference .......................................................... 77 5.3 Configure the Framework ................................................................................................. 84

5.3.1 Customer configuration ....................................................................................... 84 5.3.2 Routing configuration........................................................................................... 84

5.4 Trigger and Start the Process........................................................................................... 85 5.4.1 Overview.............................................................................................................. 85 5.4.2 Sending External Requests ................................................................................. 85 5.4.3 Scheduling Internal Requests ............................................................................. 86

5.5 Monitor and Troubleshoot the Process ............................................................................ 87 5.5.1 Monitoring with the WmMonitor GUI of webMethods IS ..................................... 87 5.5.2 Monitoring transactions with the Framework GUI ............................................... 90 5.5.3 Monitoring the Server Log of webMethods IS ..................................................... 91 5.5.4 Monitoring errors and warning with HP OVO ...................................................... 92

Appendix A: WS-TASK Web Service WSDL ............................................................................ 95 Glossary .................................................................................................................................... 97



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

• It first describes the Framework Web Manager and instructions about how to configure it.

• It then documents the current list of designed Business Process Models, when and how to use them, and how to configure or customize them.

• It concludes by providing a step-by-step procedure to help you plan new system integrations.

To use this guide effectively, you should have XML/XSL knowledge and know how to program in Java if you will be creating services in those languages (to configure and customize the Framework to your integration needs).

1.1 Document Conventions

1.2 Additional Information Troubleshooting Information. Find an exhaustive list of errors and exceptions related to the Taleo Integration Framework in the Troubleshooting Guide available on the Wiki.

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


http://wiki/

http://intranet.taleo.tc/C4/C3/Taleo Connect Middleware/default.aspx


2 Integration Server and Taleo Integration Framework

2.1 Overview The Taleo Integration Framework is more than a framework. It includes several implementations that cover Integration Business Use Cases identified by the Integration Services and Integration Production teams. This means that the Framework is ready to be used after some minor configuration steps.

In addition, this framework is based on descriptive configuration files that allow implementing new Business Use Cases into the Middleware without having to code new webMethods IS packages or even new services1. To use Integration Server 3.0 Taleo Framework (Taleo Framework), you must start the webMethods Integration Server. Because the Taleo Framework is seamlessly integrated into the webMethods platform, all configurations, administration, and management tasks that you can perform for the webMethods Integration Server also apply to the Taleo Framework.

For more information about the architecture and components of the Taleo Framework, refer to the Taleo Integration Framework Administration Guide.

1 You can avoid creating new services by using XSL and other descriptive files.



2.2 Configuring the Framework You perform most of the Taleo Framework configuration tasks by maintaining descriptive XML files.

For more information about the XML configuration files used in the Taleo Framework, refer to the Taleo Integration Framework Administrative Guide.

Once the required XML files have been configured and saved on the Integration Server, the path storing these files and some other environmental settings must be configured in the Taleo Framework properties, which the webMethods Integration Server maintains in its server.cnf file. This file is used by the webMethods Integration Server and is located in the following directory: webMethods6\IntegrationServer\config You can update the configuration properties using the Taleo Framework Properties page of the Server Administrator. The procedures in this chapter describe how to access the Taleo Framework Properties page.

Note: When you use the Taleo Framework Properties page and save your updated properties, the Taleo Framework updates all properties with the values from the Taleo Framework Properties page, including those that you might not have altered.

To view a list of the Taleo Framework configuration properties and a description of each, refer to the Taleo Integration Framework Administration Guide. To view or edit the Framework’s current configuration properties values:

1. Open the Server Administrator. 2. In the Solutions menu of the navigation panel, click Taleo Framework. The

Server Administrator opens a new browser window to display Taleo Framework-specific pages.

3. In the Settings menu of the navigation panel, click Taleo Framework Properties.



3 Working with the Framework Web Manager

3.1 Web Manager Overview The Framework Web Manager (Web Manager) is a web interface for the Taleo Integration Server 3.0 Framework (Taleo Framework). Generally, Web Manager is the equivalent of the Trading Networks Web Manager, with some limitations associated to the architecture and concept differences between the Trading Network and the Integration Framework. The features available through Web Manager are subject to enhancements in future versions that will completely streamline the configuration and the management of the Taleo Framework. Currently, Web Manager users can edit configuration settings, reload configuration profiles, schedule new integration tasks, search for documents, and check document content.

Note: As opposed to the Trading Networks, that is document-oriented, the Taleo Framework is transaction-oriented. You cannot monitor the status of Framework transactions using the Web Manager. To monitor these transactions, use the webMethods WmMonitor. For more information, see “Monitoring with the WmMonitor GUI of webMethods IS” on page 87.

3.2 Getting Started with the Web Manager 3.2.1 How to Access Web Manager For Web Manager to be available, your Integration Server must be running.

To access Web Manager, a user needs the following:

The URL for the Web Manager web site.

A valid user name and password for a webMethods IS account that belongs to the Everybody, Administrators, or ISFrameworkAdministrators group.



3.2.1.1 The Web Manager’s URL To access Web Manager, a user enters the following URL that references the main page for Web Manager:

http://HostName:PortNumber/TaleoFrameworkCoreV1

http The protocol. If you are using HTTPS, use “https” in place of “http”.

HostName The host name of the Integration Server that is running IS 3.0 Taleo Framework.

PortNumber The port number on which the Integration Server listens for incoming requests.

TaleoFrameworkCoreV1 The name of the package where Web Manager files reside.

3.2.1.2 The User Account Used to Access Web Manager Currently, only internal users have access to Web Manager. An internal user is any user within Taleo Corporation. That is, external partners or customers do not have access to Web Manager.

You must create the user accounts for internal users. For more information, see “Creating the IS User Account for Internal Users” on page 10. These user accounts have either partner or administrative authority:

- If the user account has administrative authority it must be a member of either the ISFrameworkAdministrators or the Administrators group. A user who is a member of the ISFrameworkAdministrators but not a member of the Administrators group will have access to administrative tasks for the Integration Framework but not to administrative tasks of the webMethods Integration Server (through the Server Administrator Page). A user who is a member of the Administrators group will have access to both administrative tasks of the Integration Framework and administrative tasks of the webMethods Integration Server.

- If the user account has only partner authority, it must be a member of the Everybody group. A newly created user is automatically a member of the Everybody group. Anonymous users cannot have access to Web Manager.

Creating IS User Accounts for Internal Users

To allow an internal user to access Web Manager, you need to create an Integration Server (IS) user account for the user.

To grant administrative authority to this user account, you need to assign this user account a group whose members are permitted to use the resources to which the ISFrameworkAdministrators ACL is assigned.

To grant partner authority to this user account, you need to assign this user account a group whose members are permitted to use the resources to which the ISFrameworkUsers ACL is assigned.



After creating the user account, inform the internal user of the user name and password for the user account.

Note: To be the least intrusive as possible with the existing webMethods Integration Server security settings, the installation of the Taleo Framework automatically grants any IS administrator with administrative authority on the Taleo Framework and any other user with partner authority on the Taleo Framework.

Creating the IS User Account

Perform the following procedure to create the IS user account.

To create an IS user account for an internal user: 1. Start the Integration Server. For instructions on how to start the server, see the

webMethods Integration Server Administrator’s Guide.

2. Open the Server Administrator. See the webMethods Integration Server Administrator’s Guide.

3. In the Security menu of the Navigation area, click Users and Groups.

4. Click Add and Remove Users.

5. In the Create Users section, specify the following information:

For this parameter Specify…

User Names A unique user name made up of any combination of letters, numbers, or symbols. User names are case-sensitive; be sure to use the exact case you want the internal user to specify when accessing Web Manager

Password A password made up of any combination of letters, numbers, or symbols. Passwords are case-sensitive; be sure to use the exact case you want the internal user to specify when accessing Web Manager

Re-Enter Password The same password again to ensure that you typed it correctly

6. Click Create Users.

Assigning the User Account to the ISFrameworkAdministrators group

If the user account does not need administrative authority or if the user account is already granted IS administrative authority, skip this procedure. Use this procedure only if the user account should be granted administrative authority on the Taleo Framework but not on the rest of the Integration Server.

To assign the IS user account to ISFrameworkAdministrators group:



1 Start the Integration Server. For instructions on how to start the server, see the webMethods Integration Server Administrator’s Guide.

2 Open the Server Administrator. See the webMethods Integration Server Administrator’s Guide.

3 In the Security menu of the Navigation area, click Users and Groups.

4 In the Groups section, select the group ISFrameworkAdministrators from the Select group list. The server displays the current members of the selected group in the Users in this Group list and all other defined users that are currently not members of this group in the Remaining Users list.

5 Select the IS user account you created for the internal user from the Remaining Users list.

6 Click <- (under the Remaining Users list) to make the IS user account a member of the selected group.

7 Click Save Changes.

3.2.2 Logging into the Web Manager Users can log into Web Manager by pointing their web browser to the Integration Server that is running the Taleo Framework and the main page of Web Manager. Users can access Web Manager at any time, as long as the Taleo Framework is installed on this Integration Server.

The Integration Server authenticates a user before allowing the user access to Web Manager. That is, the user must supply a valid user name and password for a webMethods Integration Server (IS) user account that has either partner authority (member of the Everybody group) or Taleo Framework administrative authority (member of the Administrators group or ISFrameworkAdministrators group).

Note: Because Web Manager uses HTML pages with frames, users need to use a frames-capable web browser to access Web Manager.

To log into Web Manager: 1 Start the web browser.

2 Point the web browser to the location of the TaleoFrameworkCoreV1 main page. For example, if the host name of your Integration Server is “ISServer”, the port number is 5555, and the file or the package is “TaleoFrameworkCoreV1”, the user would enter the following URL: http://ISServer:5555/TaleoFrameworkCoreV1 Note: If you are using a secure connection, use https instead of http. For more information about the URL to specify, see “The Web Manager’s URL” on page 10.



3 When prompted for a user name and password, enter the user name and password for the user account to access Web Manager. See “The User Account Used to Access Web Manager” on page 10.

Note that the dialog box format that appears depends on the web browser being used.

4 Click OK.



3.2.3 The Web Manager Page You will be working with two frames on the Web Manager page: the Contents frame and the Main frame.

This frame… Displays…

Contents The Web Manager tasks available to the user. You can configure what specific users see in the Contents frame and limit access to the actions in Contents frame. For more information, see “The Contents Frame” on page 15.

Main A page related to the action selected in the Contents frame. When a user with partner authority first logs into Web Manager, the Welcome page is displayed. When a user with administrative authority first logs into Web Manager, the Taleo Framework Properties page is displayed.



Based on the action a user selects in the Contents frame, Web Manager displays a corresponding page in the Main frame. For example, if a user selects the Scheduler action, Web Manager displays the Scheduler page.

Some Web Manager options are only available to users with administrative authority (member of the Administrators group or ISFrameworkAdministrators group). For example, users with partner authority (member of the Everybody group) cannot edit the Configuration options on the Configuration page and users with administrative authority can. See “Web Manager User Authority: Administrator vs. Partner” on page 25.

3.3 What You Can Configure with Web Manager 3.3.1 The Contents Frame The Contents frame contains the Web Manager tasks (or actions) available to the user.

The following shows the Contents frame and the actions that Web Manager might display for a user with administrative authority. Other users would only see a limited set of tasks.

3.3.2 The Scheduler Page 3.3.2.1 Overview

Use the Scheduler Page to view the list of scheduled integration tasks (also referred to as commands) and remove tasks from the schedule. Think of this page as a filtered view of the Server Scheduler screen available in the Server Administrator enhanced for the Integration Framework needs.

Integration tasks are listed by customer. If no specific customer is selected from the list, the page displays all scheduled integration tasks.

To configure when a specific integration task or command should be executed, you can add, edit, suspend, resume, or delete scheduled tasks.



Note: You can only schedule an integration task for a customer if the customer configuration file contains commands. For assistance in configuring or adding new commands to a customer configuration file, see the Taleo Framework Administration Guide.

One-Time and Simple Interval Tasks

This section displays tasks that are scheduled to execute a single time or at a simple repeating interval. For simple interval tasks, the server continues to execute the service until you cancel the scheduled task, or if the task does not persist after restart, until the server is restarted.

Service This field is read-only. All scheduled tasks trigger a single Integration Framework service named taleo.is.framework.core.v1.scheduler.task:publishCommand.

Task Displays the name of the integration task to be executed. Run As User Displays the user name under which the scheduled integration task runs (i.e., Administrator).

Interval Displays the frequency at which the integration task runs. Displays "once" if the integration task is scheduled to execute a single time. For a repeating task, this field shows the number of seconds that the server waits between executions of the integration task. For example, if you want the server to execute the integration task every 24 hours, it will show 86400 seconds.

Next Run Specifies the number of seconds until the next execution of the integration task.

Active



Indicates whether this scheduled integration task is active or suspended. To temporarily suspend a scheduled task, click the Active link. If a task is suspended, it will not execute at its scheduled times. To reactivate a suspended task, click the Suspended link.

Remove Deletes the task from the schedule. To delete a task, click the icon in the Remove column.

Complex Repeating Tasks

This section displays those tasks that are scheduled to run at irregular intervals.

Service This field is read-only. All scheduled tasks trigger a single Integration Framework service named taleo.is.framework.core.v1.scheduler.task:publishCommand Task Displays the name of the integration task to be executed. Run As User Displays the user name under which the scheduled integration task runs (i.e., Administrator).

Interval Displays the criteria that specifies the dates and times the integration task is to run.

Next Run Specifies the number of seconds until the next execution of the integration task.

Active Indicates whether this scheduled task is active or suspended. To temporarily suspend a scheduled task, click the Active link. If a task is suspended, it will not execute at its scheduled times. To reactivate a suspended task, click the Suspended link.

Remove Deletes the task from the schedule. To delete a task, click the icon in the Remove column.

3.3.2.2 Creating a new Scheduled Integration Task

Click “Create a scheduled task” on the main Scheduler Page to schedule a task.



Service Information

Use this section to specify information about the integration task you want to schedule.

Customer Select the customer identifier for which this integration task should be created.

folder.subfolder:service This field is read-only. All scheduled tasks trigger a single Integration Framework service named taleo.is.framework.core.v1.scheduler.task:publishCommand

Task



Select one of the preconfigured command identifiers found for this customer. This command will be processed according to the specified schedule (see Schedule Type and Details below). Run As User Specifies the user name under which the service runs (i.e., Administrator). The service is protected by the ISFrameworkUsers ACL, so be sure to specify a user name that is authorized to invoke this service.

Persistence Specifies whether you want the server to maintain the scheduled integration task if the server is restarted before it completes all scheduled executions. Enable this option if you want the server to continue to execute the schedule after the server is restarted.

Clustering

Clustered servers only. Specifies whether the service is permitted to run on any server in the cluster.

Schedule Type and Details

Use this section to define the schedule for the service.

Run Once Select this option if you want to schedule the integration task to execute once, at a specified date and time. To schedule a one-time execution, enable the Run Once option, then specify the following:

In this field… Specify…

Date The day you want the integration task to execute. Use the yyyy/mm/dd format.

Time The time you want the integration task to execute. Use the hh:mm:dd format (24-hour clock).

Repeating Select this option if you want to schedule the service to repeat at a specified interval (i.e., every 20 minutes). To define a repeating schedule, enable the Repeating option, then specify the following:


Interval The number of seconds between executions of the integration task. For example, if you want the server to execute the integration task every 30 minutes, specify 1800 seconds. If you want it to execute every 24 hours, specify 86400 seconds.




Time Whether the interval timer begins when the service starts or when the service ends. By default, the interval timer begins when the task starts. However, there may be times when you want the interval timer to start when a service ends. For example, suppose your repeat interval is 60 seconds. If a task sometimes takes longer than 60 seconds to complete, you will want to start the interval timer when the task ends so that the executions do not overlap. When you want the interval timer to start when the integration task ends, enable the Repeat from end of invocation option.

Note: When you use a repeating schedule, the integration task executes for the first time when you save these settings.

Complex Repeating Select this option if you want to schedule the service to execute at specified times on particular days of the week or month (i.e., the 15th of every month). To define a complex schedule, enable the Complex Repeating option, then specify the following:


Start Date Optional. The time you want the server to begin executing the integration task. Use the hh:mm:ss format (24-hour clock). If you leave this field blank, the server uses 00:00:00 (midnight).

Start Time Optional. The date you want the server to execute the integration task for the first time. Use the yyyy/mm/dd format. If you leave this field blank, the server executes the task on the first date specified by the remaining settings.

End Date Optional. The last date you want the server to execute the integration task for the last time. Use the yyyy/mm/dd format. If you leave this field blank, the server executes the service indefinitely.

End Time Optional. The time on the last date you want the server to execute the service for the last time. Use the hh:mm:ss format (24-hour clock). If



In this field… Specify… you leave this field blank, the server uses 00:00:00 (midnight).

Run Mask The days and times you want this service to run.

Save Task Saves the specified schedule. Schedules take effect immediately.

3.3.3 The Configuration Page When a Web Manager user selects the Configuration action from the Contents frame, Web Manager displays the Configuration page. The Configuration page allows users to reload configuration files and to reset the date of the last execution of specific queries.

Note that the Configuration Page is only available to users having administrative authority.

3.3.3.1 Reset Query Last Run Date

The Reset Query Last Run Date lets you reset the date of the last execution of a query to a specific date.

A query is identified by a RequestID, which is the combination of a sender identifier, an event identifier and a receiver identifier, each separated by the “@” character.

Customer identifier Select the customer identifier for which this integration task should be created.

RequestID Select the sender identifier, the event identifier and the receiver identifier that corresponds to the query to which you want to reset the last run date. The Taleo Framework keeps track of the last run date with sender@event@receiver. For example, if for customer UNIT_TEST_CLIENT_ID the sender is the Onboarding application, the receiver is the Professional application and the event is OLF synchronization, then you may set the values as in the above screen shot.

Last Run Date to reset to



Set the date to which you want to reset the last run date. You may choose any valid date pattern, as long as the pattern matches that specified in the Using date format field.

Using date format Set the date format used in the previous field. If the date format is invalid or if the date format does not match the value entered in the previous field, an error will be thrown.

3.3.3.2 Reload Configuration Files

The Reload Configuration Files link in the Configuration page allows users to reload modified or added customer configuration files and to unload deleted customer configuration files.

The message displayed above should appear if no customer configuration files have changed since the last reload.

3.3.4 Document Submission Page When a Web Manager user selects the Document Submission action from the Contents frame, Web Manager displays the Submission page. The Submission page allows users to send directly documents to the Integration Framework, without needing a specific HTTP/S client or to schedule a specific command in the Scheduler.

The Submission page is the equivalent to the Submission page available in the Trading Networks Web Manager, except you can use it to send any kind of document, not only



XML documents. For example, you can send T-SOAP documents, RS-XML documents, CSV documents, PGP encrypted documents, or even SOAP requests to web services hosted on the Integration Server (i.e., to retrieve the list of currently registered Taleo Onboarding external tasks).

When sending T-SOAP/RS-XML documents or sending SOAP requests to be routed to the RPC gateway of the Integration Server (synchronous web-service invocation), you can directly paste the document content in the Text area and click on the Send Document button.

When sending other kinds of documents you will need to add some additional parameters to provide routing information to the Integration Framework. This is required because this routing information is not part of the document or because the Integration Framework is not able to extract this information automatically.

To add this information, click the Show Additional Parameters link under the Text area.

Document Enter the document content you want to submit to the Integration Framework.

Customer identifier Select the customer identifier on behalf of whom you want to send the document. This field is disabled for users without administrative authority. In this case, it takes the customer identifier corresponding to the logged username.



Sender identifier Select the delivery method in the list used to deliver the results of the submitted request (if any). The delivery method is bound to a specific application type. The application type and the version associated in the configuration file will determine which routing should apply while processing the document.

If no routing applies for this type and version of source application, you will receive an error while sending the document.

Receiver identifier Select the delivery method in the list used to deliver the request document. The delivery method is bound to a specific application type. The application type and the version associated in the configuration file will determine which routing should apply while processing the document.

If no routing applies for this type and version of target application, you will receive an error while sending the document.

You may also leave the receiver identifier at “(autodetect)” instead of specifying explicitly a delivery method. This way, the Integration Framework will try to detect automatically the proper receiver(s) for this document, based on the published event identifier.

There might be more than one listener on the specified event identifier. In this case, more than one process instances are started. For example, both the Professional and Customer application types listen for the WS-IS_DEFAULT event identifier. If you send a document and specify the receiver identifier to be auto-detected, two instances are started, one targeted to the customer system and one to the Taleo Professional customer zone.

Business Process identifier Select the specific business process identifier that you want to process the document. Usually, you should not be set explicitly the process identifier but left at “(autodetect)” instead. Thus, the business process identifier will be automatically determined while processing the document, according to the routing configuration file corresponding to the target application type (specified by the Receiver identifier).

Event identifier Select the identifier of the event to be published to the webMethods Broker in order to process the request document.

3.3.5 Transactions Page When a user selects the Transactions action from the Contents frame, Web Manager displays the Transactions page. This page displays criteria used to search for documents in the Taleo Framework. The Transactions page also contains options to indicate how Web Manager displays search results.



The Document ID searches for documents hosted on the Taleo Framework Repository. The Document ID is a native identifier that is generated by the Taleo Framework when the document is received.

You can also enter only parts of the Document ID. For example, entering NIKE in this field will search for Document IDs beginning with, ending with, or containing the word NIKE.

The Last modified date option sorts the query results by their last modification date. Descending displays the newest documents first, ascending the oldest first.

The Maximum Results option indicates the maximum number of documents returned in the query results.

The Search button starts the search and displays the query results.

3.4 Configuring Web Manager 3.4.1 Configuring and Web Manager User Authority You can configure Web Manager based on the authority of the user. When a user accesses Web Manager, Web Manager follows a set of rules to determine the actions to display for that user.

3.4.1.1 Web Manager User Authority: Administrator vs. Partner

A user accessing Web Manager must have either administrative or partner authority:

Administrative – Users that are allowed to use resources controlled by the ISFrameworkAdministrators ACL. Web Manager users with administrative authority can configure scheduled integration tasks, reload configuration files, reset query last execution date, and configure the Taleo Framework properties. Some Web Manager actions and options are only available to users with administrative authority. For example, the Taleo Framework Properties Settings can only be edited by users with administrative authority.

Partner – Users that are allowed to use resources controlled by the ISFrameworkUsers ACL. Web Manager Users with partner authority can only view the Taleo Framework Properties settings; they cannot edit these settings, nor can they add, edit, or remove Integration Scheduled Tasks.

For more information on how to grant a user account administrative or partner authority, see “The User Account Used to Access Web Manager” on page 10.



3.4.2 About the Taleo Framework Properties Page Updating properties on the Taleo Framework Properties page changes the properties in the Integration Server server.cnf file. The server.cnf file is located in the webMethods\IntegrationServer\config\ directory, where webMethods\IntegrationServer is the directory in which your Integration Server is installed.

You can add properties not currently listed on the Taleo Framework Properties page. If the property you want to set is not listed, add it by making a new line on the Taleo Framework Properties page. Be sure you use the correct case.

Note: You can also use the Server Administrator Extended Settings Page to view, add, or edit Taleo Framework Properties.

For more information about the list of existing Taleo Framework properties and their individual description, see the Taleo Integration Framework Administration Guide.



4 Working with the Business Process Models of the Framework

4.1 Definitions 4.1.1 What is a Business Process A Business Process is a recipe for achieving a commercial result. Each business process has an input, method and output. The input is a pre-requisite that must be in place before the method can be put into practice. When the method is applied to the input, then certain output will be created.

A Business Process is a collection of related structural activities that produce something of value to the organization, its stake holders, or its customers. It is, for example, the process through which an organization realizes its services to its customers.

A Business Process can be part of a larger, encompassing process and can include other business processes that have to be included in its method. In this context, a business process can be viewed at various levels of granularity. The link between business processes and value generation leads some practitioners to view business processes as the workflows which realize an organization's use cases.

A Business Process can be thought of as a cookbook for running a business; “Place an order,” “Answer the phone,” "Archive some candidates data,” “Export some customer data,” or “Replicate two HR systems" might all be examples of a Business Process.

A Business Process is usually the result of a business process design or business process reengineering activity.

4.1.2 What is a Business Process Model A Business Process Model (BPM) provides a description of the business logic and rules from a functional point of view.

A BPM uses diagrams that show the interaction between processes, flows, messages, and resources from one or several start points to all potential end points.



4.1.3 Taleo Framework Business Process Models The BPMs available in the Taleo Framework cover typical Taleo integration business processes.

Created with the webMethods Modeler Design Tool (WmModeler), these models are managed by the webMethods Process Run Time (WmPRT) and can be monitored using the webMethods Monitor (WmMonitor).

The Taleo Framework Business Process Models are documented in the following sections. Each section covers the documentation of a BPM that includes:

- A model definition.

- A step definition.

- The model requirements, criteria, or limitations.

- A list of typical Business Uses Cases.

- A list of built-in scenarios.

From a Taleo Framework perspective, each scenario corresponds to an event that starts a specific BPM. Each event is associated to a specific Business Use Case and has a unique identifier called EventID.

- A procedure to handle new scenarios (or events) when supported by the model.



4.2 WS-IS – Standard Data Integration

4.2.1 Model definition WS-IS models the exchange of a document from a system to another using guaranteed delivery. This is the simplest model of the Taleo Framework where no transformation of the document content is required.

Guaranteed delivery ensures the sender that the document will be successfully delivered to the intended receiver, whatever the communication or technical problems encountered while trying to deliver the document.

With this model, the Integration Framework acts as a gateway by:

- Decrypting the content of the document, if required.

- Delivering the decrypted document to its ultimate receiver, specified as model input.

- Waiting for a response, if expected (otherwise completing the transaction).

- Encrypting the content of the document, if required.

- Replying to the sender with the encrypted document (then completing the transaction).

The model supports both the request-only and the request-response Message Exchange Patterns (MEP). This means that a process instance may be completed after successful delivery of the initial request document. Only when the user expects a response document



to its initial request document (request-response MEP) does the model wait for a response document that it forwards back to the sender.

4.2.2 Step definition

Step Name Service Name Description R

Start transaction

startSvc This step performs a validation of the sender and receiver identifiers specified as model input.

It then generates an identifier specific to this transaction that all documents traversing this model instance will carry (used for correlation purposes).

Finally, it saves transactional data in the model runtime engine (GlobalData of the PRT) in order to ensure guaranteed delivery.

X

Decrypt request

decryptRequestSvc This step decrypts or validates the request document against a specific PGP signature key if the customer configuration associated to the sender indicates that this sender sends its documents encrypted, signed, or both.

X

Deliver (decrypted request)

deliverRequestSvc If the document format is recognized by the Framework*, this step appends some transactional data to the document header (needed for correlation purposes).

It then logs the document to be delivered to the monitoring console

Finally, it delivers the document to the ultimate receiver associated with the identifier specified as model input, using guaranteed delivery. *Only T-SOAP and RS-XML document formats are currently recognized by the Taleo Framework.

X

Receive result

receiveResultSvc This step logs the document being received to the monitoring console.

X

Encrypt result

encryptResultSvc This step encrypts or signs the response document if the customer configuration associated to the sender indicates that it expects the reception of documents to be encrypted, signed, or both.

X

Deliver result

deliverResultSvc See description associated to Deliver (decrypted request) step.

X

Ack transaction

ackReceivedSvc This step publishes a message acknowledging that the transaction



Step Name Service Name Description Rreception was successfully started and the

document is being processed. This message refers the instance identifier created in the Start transaction step.

Ack transaction completion

ackDoneSvc This step publishes a message acknowledging that the transaction was successfully completed. This message refers the instance identifier created in the Start transaction step.

Handle timeout

timeoutHandlerSvc This step publishes a message indicating that the transaction timed out after a given lapse of time. This message refers to the instance identifier created in the Start transaction step.

Handle error

errorHandlerSvc This step publishes a message indicating that an error occurred while processing the transaction. This message refers to the instance identifier created in the Start transaction step and the detailed error occurred.

4.2.3 When to use this model The user should consider this model when the following integration conditions apply:

- No transformation is required other than the decryption/encryption of the transported document.

- The sender does not expect an asynchronous acknowledgment of the processing or the completion of the document (other than the response document that might be expected).

- When a document response is expected, the sender does not expect the Integration Framework to mark the transaction as failed if a business error occurrs (as opposed to communication or configuration errors). This means that if a Taleo application returns a response document containing business errors (i.e., the export request was not well-formed or the value of an XML tag is invalid), the response document will be sent back to the sender “as-is.”

4.2.4 Business Use Cases We’ve already identified the following Business Use Cases that this model covers:

- Direct data import or data export: The customer sends T-SOAP or RS-XML document(s) directly to the Integration Framework using the HTTP/S protocol; the customer expects an import or export response in the same format (T-SOAP or RS-XML respectively).

- Scheduled data import or data export: The customer sends T-SOAP or RS-XML document(s) to an FTP drop box that the Integration Framework



polls according to a specific schedule; the customer expects an import or export response in the same format (T-SOAP or RS-XML respectively).

- Scheduled candidate archiving: A Taleo application archives customer data on a scheduled basis and sends the archived data to an FTP drop box or a server directly hosted by the customer; the Taleo application does not expect a response.

- Triggered new hire export: A Taleo application triggers the export of new hires to be delivered to the customer.

- Taleo Connect Client driven integration processes: The Taleo Connect Client sends T-SOAP or RS-XML documents to the Integration Framework that routes the documents to the customer application hosted on Taleo application servers; the Taleo Connect Client directly polls the response on the customer application, therefore, the Integration Framework does not expect a response.

4.2.5 Built-in scenarios The following scenarios (events) are functional in the Taleo Framework without further configuration steps:

4.2.5.1 WS-IS_DEFAULT

If the document request does not explicitly specify an EventID, the WS-IS model uses the WS-IS_DEFAULT event. This event is mainly to support backward compatibility towards Integration Server 3.0 SP2 that accepted document requests without specifying an EventID. It is strongly recommended to use a meaningful EventID for other specific business use cases.

The associated Business Use Cases listed above are 1) Direct data import/export, 2) Scheduled data import/export, 3) Taleo Connect Client driven integration processes.

4.2.5.2 CANDIDATE_ARCHIVING

The CANDIDATE_ARCHIVING EventID is associated to the Business Use Case Scheduled candidates archiving. A Taleo Professional application issues this event when it archives candidates according to the customer’s internal schedule. The Taleo Professional application sends the candidates marked for archiving to the customer through the Integration Framework (kind of backup). The request-only MEP is therefore always used (no response is expected from the customer). Once the customer receives the candidates, the model marks the transaction as completed.

4.2.5.3 NEW_HIRE_RESPONSE

The NEW_HIRE_RESPONSE EventID is associated to the Business Use Case Triggered new hire export. An internal trigger in the Professional application requests the extraction of a new hire once a candidate moves to the hired step. The result of this extraction is sent to the customer through the Integration Framework. The request-only MEP is therefore always used (no response is expected from the customer). Once the customer receives the new hire data, the model marks the transaction as completed.

4.2.6 Handling new scenarios You can handle new scenarios by creating new EventIDs for the Taleo Framework. However, in most situations, the WS-IS_DEFAULT event should be sufficient, as this model does not involve any custom transformation step. Creating more meaningful



EventIDs may be only useful to better identify other Business Use Cases that the Taleo Framework may have to cover.

For more information on how to configure new events for the Taleo Framework, refer to “Routing configuration” on page 84.



4.3 WS-EXTRACT – Data Extraction or Data Transformation

4.3.1 Model definition WS-EXTRACT features a generic way to exchange documents between two systems involving at least one transformation, either on the document request or on the document response (if any is expected).

When two systems interact with one another, they used to “speak” a different “language.” That is, one system might use another XML format than the other, while the rest of the business process remains the same.

The guaranteed delivery between these two systems ensures that even if communication fails, the document will be successfully delivered to the intended partner (the receiver for the request, the sender for the response, if any).


- Decrypting the content of the document, if required.

- Transforming the decrypted document to the expected format of the receiver specified as model input.

- Delivering the transformed document to its intended receiver.

- Waiting for a response, if expected (otherwise completing the transaction).

- Transforming the response document, if required.

- Encrypting the possibly transformed content of the document, if required.



- Replying to the sender with the encrypted/transformed document (then completing the transaction).

The model supports both the request-only and the request-response Message Exchange Patterns (MEP). This means that a process instance may be completed after successful delivery of the initial request document. Only when the user expects a response document to its initial request document (request-response MEP) does the model wait for a response document that it forwards back to the sender.

4.3.2 Step definitions


Start transaction




X

Decrypt request

deliverRequestSvc This step decrypts or validates the request document against a specific PGP signature key if the customer configuration associated to the sender indicates that this sender sends its documents encrypted, signed, or both.

X

Transform request

transformRequestSvc This step invokes a transformation service if the document request needs a transformation before the model can deliver it. For more information on how to specify the transformation service to invoke, see “Handling new scenarios” on page 40.

X

Deliver transformed request

deliverRequestSvc If the document format is recognized by the framework*, this step appends some transactional data to the document header (needed for correlation purposes).

It then logs the document to be delivered to the monitoring console.

Finally, it delivers the document to the ultimate receiver associated with the identifier specified as model input, using guaranteed

X



Step Name Service Name Description Rdelivery. *Only T-SOAP and RS-XML document formats are currently recognized by the Taleo Framework.

Receive result


Transform result

transformResultSvc This step invokes a transformation service if the document response needs a transformation before the model can deliver it. For more information on how to specify the transformation service to invoke, see “Handling new scenarios” on page 40.

X

Deliver transformed result

deliverResultSvc See the description associated to Deliver transformed request step above.

X

Encrypt result

encryptResultSvc This step encrypts or signs the response document if the customer configuration associated to the sender indicates that it expects the reception of documents to be encrypted, signed, or both.

X

Ack transaction reception

ackReceivedSvc This step publishes a message acknowledging that the transaction was successfully started and the document is being processed. This message refers to the instance identifier created in the Start transaction step.


ackDoneSvc This step publishes a message acknowledging that the transaction was successfully completed. This message refers to the instance identifier created in the Start transaction step.

Handle timeout


Handle error

errorHandlerSvc This step publishes a message indicating that an error occurred while processing the transaction. This message refers to the instance identifier created in the Start transaction step and the detailed occurred error.




- There is at least one transformation required other than the decryption/encryption of the transported document.

- The sender does not expect an asynchronous acknowledgment of the processing or the completion of the document (other than the response document that might be expected).

- When a document response is expected, the sender does not expect the Integration Framework to mark the transaction as failed if a business error occurs (as opposed to communication or configuration errors). This means that if business errors are found in the response document coming from the Taleo application (i.e., the export request was not well-formed or the value of an XML tag is invalid), the response document will be sent back to the sender “as-is.”

- The sender cannot send a functional acknowledgment of the delivered response document, if any. If the sender sends a functional acknowledgment of the delivered response document, you should consider the WS-EXTRACT-SYS business model instead of WS-EXTRACT.

4.3.4 Business Use Cases We already identified the following Business Use Cases that this model covers:

- CSV Direct Import: The customer sends document(s) in a generic CSV format directly to the Integration Framework using the HTTP/S protocol and expects the import results in the same generic CSV format.

- CSV Scheduled Import: The customer sends document(s) in a generic CSV format to an FTP drop box that the Integration Framework polls according to a specific schedule; the customer expects the import results in the same generic CSV format.

- CSV Direct Export: The customer sends SQ-XML document(s), containing a Selection Query, to the Integration Framework using the HTTP/S protocol; the customer expects the results in a generic CSV format.

- CSV Scheduled Export: According to a specific schedule, the Integration Framework executes a predefined Selection Query (stored locally on the Integration Server) against the customer application hosted by Taleo; the customer expects the results in a generic CSV format.

- Onboarding HR-XML Export: According to the workflow specified in the Taleo Onboarding application, a talent master file is converted in HR-XML to be delivered to the customer.

- New Hire Export: According to a specific schedule, the Integration Framework executes a predefined Selection Query (stored locally on the Integration Server) against the Professional zone of a customer that



extracts all the new hired candidates since the last query execution; the customer expects the new hire results in a T-SOAP format.


4.3.5.1 SQ_EXTRACT_CSV SQ_EXTRACT_CSV_LARGE_EXTRACT SQ_EXTRACT_CSV_NO_PAGING

The SQ_EXTRACT_CSV* EventID is associated to the CSV Direct and Scheduled Export Business Use Cases. When the model starts, the request document contains an SQ-XML request. The model transforms the request to a T-SOAP request then delivers it to the Taleo Professional application. The Taleo Professional application processes it then returns a T-SOAP response document. The model transforms the T-SOAP response and generates a response in the generic CSV format. The model then sends this CSV response document back to the sender.

The transformation steps are implemented using XSL descriptive files and built-in XSL transformation services provided by the Taleo Framework.

The SQ-XML to T-SOAP transformation (applied on the request document) uses a simple XSL transformation service that wraps the SQ-XML into a valid T-SOAP request document using an XSL file.

The T-SOAP to CSV transformation (applied on the response document) also uses XSL files, but from a more evolved XSL transformation service that gently handles large content without harming the Integration Server memory (RAM). This service transforms each export result returned by the Taleo Professional application in a CSV record and streams it to the CSV response document output.

4.3.5.2 HR-XML_TASK_PUBLICATION

The HR-XML_TASK_PUBLICATION EventID is associated to the Onboarding HR-XML Export Business Use Case. When the model starts, the request document contains a T-SOAP request, containing the Onboarding Talent Master File of a candidate. The model transforms the request to an HR-XML request, and then delivers it to the customer.

4.3.5.3 NEW_HIRE_REQUEST

The NEW_HIRE_REQUEST EventID is associated to the New Hire Export Business Use Case. When the model starts, the request document contains an SQ-XML request. The model determines the last query execution date and replaces the date filter using this value. It then transforms the request to a T-SOAP request and delivers it to the Taleo Professional application. The Taleo Professional application processes it, and then returns a T-SOAP response to the Integration Framework, which routes it to the customer by default, without further transformation.



4.3.5.4 USER_IMPORT_CSV USERGROUP_IMPORT_CSV CANDIDATE_IMPORT_CSV DEPARTMENT_IMPORT_CSV JOBFIELD_IMPORT_CSV LOCATION_IMPORT_CSV ORGANIZATION_IMPORT_CSV POSITION_IMPORT_CSV REQUISITION_IMPORT_CSV UDSELEMENT_IMPORT_CSV REQUISITIONTEMPLATE_IMPORT_CSV

The following EventIDs are associated to the CSV Direct and Scheduled Import Business Use Cases:

EventID Associated RS-XML Entity

USER_IMPORT_CSV User

USERGROUP_IMPORT_CSV UserGroup

CANDIDATE_IMPORT_CSV Candidate

DEPARTMENT_IMPORT_CSV Department

JOBFIELD_IMPORT_CSV JobField

LOCATION_IMPORT_CSV Location

ORGANIZATION_IMPORT_CSV Organization

POSITION_IMPORT_CSV Position

REQUISITION_IMPORT_CSV Requisition

UDSELEMENT_IMPORT_CSV UDSElement

REQUISITIONTEMPLATE_IMPORT_CSV RequisitionTemplate

For more information on the current Standard CSV Offering, refer to the Taleo Standard CSV Import available on the [TIP].

When the model starts, the request document contains a CSV request containing some records of the associated RS-XML entity. The model transforms the request to an RS-XML request then delivers it to the Taleo Staffing Station application. The Taleo Professional application imports the entities into its database then returns an RS-XML response document, containing the result of the import process. The model transforms the RS-XML response and generates a response in a generic CSV format. The model then sends this CSV response document back to the sender.

The transformation steps are implemented using XSL descriptive files and a CSV import custom Java service.

The CSV to RS-XML transformation (applied on the request document) uses a CSV import transformation service (located in the TaleoFrameworkCSVImportV1 package) that generates an RS-XML request document populated with the data found in the CSV import request.


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


The RS-XML to CSV transformation (applied to the response document) uses XSL files from an evolved XSL transformation service that gently handles large content without harming the Integration Server memory (RAM). This service transforms each import result (and possibly business errors or warnings) returned by the Taleo Professional application in a CSV record and streams it to the CSV response document output.

4.3.6 Handling new scenarios Concretely, any new scenario requires the definition of a new EventID in the Taleo Framework. This is because the WS-EXTRACT model involves transformation steps and each new scenario (event) will likely want to customize these transformation steps.

For more information on how to customize transformation services in the Taleo Framework, “Code your Custom Transformations (optional)” on page 68.

4.4 WS-SYS – Transform and Forget

4.4.1 Model definition WS-SYS features a generic way to publish a document from one system to another, possibly involving a transformation step.

The main particularity of this model over the WS-EXTRACT model is that the WS-SYS model never sends back a response document to the sender of the request document. In that, it always implements from a sender point of view a request-only MEP, also referred to as fire-and-forget pattern in common messaging solutions.

Fire-and-forget means that the system tries, on a best effort basis, to deliver the document to the intended partner (using guaranteed delivery), without requiring the sender to wait for a response (neither synchronously nor asynchronously). In other terms, the sender



assumes that the document transaction is successfully completed as soon as the model acknowledges the start of the transaction, even if the started transaction itself is not yet completed.

In addition, the model always expects the receiver to return a response document and allows optional parsing of the response document in order to detect business errors (that is, errors returned by the receiver itself, as opposed to communication or runtime failures).


- Optionally transforming the document request to the expected format of the receiver specified as model input.

- Delivering the transformed document to the intended receiver.

- Waiting for a response document for a given lapse of time.

- Optionally parsing the response document for business errors.



Start transaction



Finally, it saves transactional data in the model runtime engine (GlobalData of the PRT) to ensure guaranteed delivery.

X

Transform request

transformSvc This step invokes a transformation service if the document request needs a transformation before the model can deliver it. For more information on how to specify the transformation service to invoke, see “Handling new scenarios” on page 44.

X


deliverSvc If the document format is recognized by the framework*, this step appends some transactional data to the document header (needed for correlation purposes).

It then logs the document to be delivered to the monitoring console.

Finally, it delivers the document to the ultimate receiver associated with the identifier specified as model input, using guaranteed delivery.

X



Step Name Service Name Description R*Only T-SOAP and RS-XML document formats are currently recognized by the Taleo Framework.

Check results for errors

checkErrorSvc This step logs the document being received to the monitoring console.

If the document is recognized by the framework*, it then parses the received document for business errors. If the service finds errors, it throws an exception to mark the transaction as failed. *Business error detection is only implemented for T-SOAP and RS-XML document formats by the Taleo Framework.





Handle timeout


Handle error





- There is no decryption/encryption involved in the integration process.

- The sender does not expect or cannot receive a response to its request document.

- The receiver always returns a response document (i.e., functional acknowledgment).

- The Integration Framework has the requirement to monitor business errors that occurred on the receiver system (optional condition).


- Application Data Publishing: An application publishes some data entities to the Integration Framework so subscribers that have registered to these entities get notified and take action (i.e., start an internal process).


4.4.5.1 START_OB_PROCESS

The START_OB_PROCESS EventID is associated to the Application Data Publishing Business Use Case. When a candidate moves to the hired status in the Taleo Professional application, a service triggers the export of the associated NewHire entity and publishes the results of this export to the Integration Framework using the START_OB_PROCESS EventID. Because the Taleo Onboarding application registered itself as a listener for this event, a WS-SYS model instance starts and transforms the document request into an import request of an Onboarding TalentMasterFile entity. The model delivers the request to the Onboarding application, which returns the import results. It then parses the import results for business errors, and if no error has occurred, marks the transaction as successfully completed.

The transformation steps are implemented using XSL descriptive files.

To transform the NewHire export result into a TalentMasterFile import request, this scenario uses an evolved XSL transformation service that gently handles large content without harming the Integration Server memory (RAM).

To parse the TalentMasterFile import results for errors, this scenario uses the default built-in service of the model that currently supports both T-SOAP and RS-XML formats.

4.4.5.2 UPDATE_OB_START_DATE

The UPDATE_OB_START_DATE EventID is associated to the Application Data Publishing Business Use Case. The NewHire entity, published by the Taleo Professional application while moving a candidate to the hired status (see START_OB_PROCESS scenario), includes a start date representing the date where the “on-boarding” process associated to this new employee should start. Under some circumstances, this start date might change in the Taleo Professional application (i.e., the new hired candidate



availability changed over the time). In this particular situation, the Taleo Onboarding application should reflect the new start date in its internal processes. The Taleo Professional application therefore publishes an UPDATE_OB_START_DATE EventID for this purpose to the Integration Framework. Because the Taleo Onboarding application registered itself as a listener for this event, a WS-SYS model instance starts and transforms the document request into an Onboarding application specific entity. The model delivers the request to the Onboarding application, which returns the update results. It then parses the updated results for business errors, and if no error occurred, marks the transaction as successfully completed.

The transformation steps are implemented using XSL descriptive files, using the same kind of transformation services as documented in the START_OB_PROCESS scenario.

4.4.5.3 CANCEL_OB_PROCESS

The CANCEL_OB_PROCESS EventID is associated to the Application Data Publishing Business Use Case. Once the “on-boarding” process of a candidate has started it may happen that either the candidate or the manager want to cancel the hiring process. For example, the candidate may not show up on the employment start date, or the hiring manager might have started an on-boarding process for the wrong candidate. In any of these situations, the on-boarding internal processes in the Taleo Onboarding application have to be canceled. The Taleo Professional application therefore publishes a CANCEL_OB_PROCESS EventID for this purpose to the Integration Framework. Because the Taleo Onboarding application registered itself as a listener for this event, a WS-SYS model instance starts and transforms the document request to an Onboarding application specific entity. The model delivers the request to the Onboarding application, which returns the canceling results. It then parses the canceling results for business errors, and if no errors occurred, marks the transaction as successfully completed.

The transformation steps are implemented using XSL descriptive files, using the same kind of transformation services as documented in the START_OB_PROCESS scenario.

4.4.6 Handling new scenarios Concretely, any new scenario requires the definition of a new EventID in the Taleo Framework. This is because the WS-EXTRACT model involves a transformation step and each new scenario (event) will likely want to customize this transformation step.

For more information on how to customize transformation services in the Taleo Framework, see “Code your Custom Transformations (optional)” on page 68.



4.5 WS-EXTRACT-SYS – System to System Synchronization

4.5.1 Model definition Simply put, the WS-EXTRACT-SYS model is the aggregation of the WS-EXTRACT and the WS-SYS models (see illustration below).

This model therefore features a generic way to exchange documents between two systems involving at least one transformation—either on the document request or on the document response (if any expected)—that always expects the second system to return a response document. It allows optional parsing of the document response received by the



second system in order to detect business errors (that is, errors returned by the receiver itself, as opposed to communication or runtime failures).

This model is typically used between two Taleo applications that include a Connect Server (formerly known as ITK), as the Connect Server is able to return asynchronous responses to incoming requests.


- Optionally transforming the document request to the expected format of the receiver specified as model input.

- Delivering the transformed document to the intended receiver.

- Waiting for a response document for a given lapse of time.

- Optionally parsing the response document for business errors.



Start transaction

startSvc This step performs a validation of the sender and receiver identifiers specified as model inputs.



X

Decrypt request

decryptRequestSvc This step decrypts or validates the request document against a specific PGP signature key if the customer configuration associated to the sender indicates that this sender sends its documents encrypted, signed, or both.

X

Transform request

transformRequestSvc This step invokes a transformation service if the document request needs a transformation before the model can deliver it. For more information on how to specify the transformation service to invoke, see “Handling new scenarios” on page 40.

X


deliverRequestSvc If the document format is recognized by the framework*, this step appends some transactional data to the document header (needed for correlation purposes).

X




It then logs the document to be delivered to the monitoring console

Finally, it delivers the document to the ultimate receiver associated with the identifier specified as model input, using guaranteed delivery. *Only T-SOAP and RS-XML document formats are currently recognized by the Taleo Framework.

Receive result


X

Transform result

transformResultSvc This step invokes a transformation service if the document response needs a transformation before the model can deliver it. For more information on how to specify the transformation service to invoke, see “Handling new scenarios” on page 49.

X

Deliver transformed result

deliverResultSvc See the description associated to Deliver transformed request step above.

X

Check results for errors

checkResultErrorSvc This step logs the document being received to the monitoring console.

If the document is recognized by the framework*, it then parses the received document for business errors. If the service finds errors, it throws an exception to mark the transaction as failed. *Business error detection is only implemented for T-SOAP and RS-XML document formats by the Taleo Framework.





Handle timeout

timeoutHandlerSvc This step publishes a message indicating that the transaction



Step Name Service Name Description Rtimed out after a given lapse of time. This message refers to the instance identifier created in the Start transaction step.

Handle error



- The sender does not expect or cannot receive a response to the request document.

- There is at least one transformation required other than the decryption of the document request.

- The document request should be executed against another system than the ultimate receiver (also referred to as the second system). If the document request should be directly executed against the second system, consider the WS-SYS business model instead of the WS-EXTRACT-SYS.

- There is no encryption required by the second system.

- The second system always returns a response document (i.e., functional acknowledgment). If the second system cannot send a response document, you should consider the WS-EXTRACT business model instead of the WS-EXTRACT-SYS.

- The Integration Framework has the requirement to monitor business errors that occurred on the receiver system (optional condition).


- System to system synchronization: A request is sent that extracts some data from a system and synchronizes this data with another system.


4.5.5.1 FOUNDATION_DATA_SYNC

The FOUNDATION_DATA_SYNC EventID is associated to the System to system synchronization Business Use Case. The Onboarding application needs to have the



foundation data (like Organizations, Locations, JobFields, Job Templates, Positions or Departments) in-sync with the Taleo Professional application.

An SQ-XML request that extracts some foundation data from the Taleo Professional application is stored on the Integration Server and an integration task is scheduled for this purpose in the Taleo Framework Scheduler. When the scheduled task executes, it publishes a FOUNDATION_DATA_SYNC EventID along with this pre-stored SQ-XML request. Because the Taleo Onboarding application registered itself as a listener for this event, a WS-EXTRACT-SYS model instance starts and transforms the SQ-XML request into an export request of the Taleo Professional application. The model delivers the export request to the Taleo Professional application, which returns the corresponding export results. The model then transforms these export results into an import request specific to the Taleo Onboarding application. The model delivers the import request to the Taleo Onboarding application, which returns the import results. It then parses the import results for business errors, and if no errors occurred, marks the transaction as successfully completed.

4.5.5.2 WORKER_CANDIDATE_CONVERSION

The WORKER_CANDIDATE_CONVERSION EventID is associated to the System to system synchronization Business Use Case. The Taleo Professional application needs to have the WorkerCandidate entities in-sync with the Taleo Contingent application. In addition, the Contingent application needs to be able to synchronize its data with any Taleo Professional application (including older ones that did not yet support the T-SOAP XML format).

Taleo Contingent therefore issues an import request, according to an internal schedule (or on-demand), to its internal Connect Server that executes and returns the results to the Integration Framework, using the WORKER_CANDIDATE_CONVERSION EventID. Because the Taleo Professional application registered itself as a listener for this event, a WS-EXTRACT-SYS model instance starts and transforms the import results into an RS-XML import request. The model delivers the import request to the Taleo Professional application, which returns the import results in an RS-XML response. The model then transforms the import results into a T-SOAP request specific to the Taleo Contingent application. The model delivers this request to the Taleo Contingent application, which returns the integration results. It then parses the integration results for business errors, and if no errors occurred, marks the transaction as successfully completed.

4.5.6 Handling new scenarios Concretely, any new scenario requires the definition of a new EventID in the Taleo Framework. This is because the WS-EXTRACT-SYS model involves several transformation steps and each new scenario (event) will likely want to customize these transformation steps.

For more information on how to customize transformation services in the Taleo Framework, see “Code your Custom Transformations (optional)” on page 68.



4.6 WS-TASK – Task Processing

4.6.1 Model definition The aim of the Taleo Framework is to cover most of the Taleo integration standard needs to reduce the overhead of rewriting processes for a customer that were already implemented for another customer. Thus, the integration consultant can concentrate on customizing the transformation steps (if any) either with custom mappings, using XSL files, or by creating module Java services, and later easily reusing with other customers.

However, some integration processes or mappings are more complex and involve a specific workflow, i.e., in order to integrate Taleo systems with other HRMS.

To cover this need, the WS-TASK model enables the delegation of specific integration tasks (or process/workflow) to customer or external system specific packages (i.e., SAP, PeopleSoft, etc.).

In this scope, an integration task is associated to a specific customer or a specific application type and is defined by:

- its ability to acknowledge the sender of the functional task reception or not (functional reception in a business sense proper to the external system)

- its ability to notify the sender about the functional task completion or not (functional completion in a business sense proper to the external system)




- Identifying and validating the integration task to be processed.

- Delivering the integration task request to the module processing the task.

- If the integration task is able to acknowledge the functional task reception, it waits for this acknowledgment notification and forwards it to the sender.

- If the integration task is able to notify about the functional task completion, it waits for this completion notification and forwards it to the sender.

4.6.1.1 Integration Task Registration

The Integration Tasks supported by the WS-TASK model may evolve over the time. Once deployed in Production, new business needs may appear, and the WS-TASK has to support these needs without having package or BPM redeployment.

To achieve this, the WS-TASK model uses a registration mechanism that allows adding new implementations over the time.

The package or module that implements the new Integration Task has to register its task(s) to the WS-TASK. Each task being registered specifies:

- its name.

- the customer for which it applies.

- the application types for which it applies.

- its ability to provide a task reception acknowledgment.

- its ability to provide a task completion notification.

The model generates a unique task identifier for each task registration. Similarly, the package or module may unregister the task(s) it implements.

To start a WS-TASK model instance, the sender must invoke a web service that returns the list of currently implemented Integration Tasks (filtered by customer or application type), and sends a request containing the unique task identifier corresponding to the task to be processed.



Start transaction

startSvc This step performs a validation of the sender and task identifiers specified as model inputs. The model instance will fail if the specified task identifier is not

X



Step Name Service Name Description Rregistered.



Deliver request

sendRequestSvc This step extracts the SOAP-Body part of the document request (precisely the T-SOAP Document part situated in the SOAP-Body part).

It then logs the resulting Document part to the monitoring console.

Finally, it invokes the callback service specified by while registering the task and passes this Document part to it for processing.

X

Receive ack

receiveAckSvc If the task supports the reception acknowledgment notification, this step waits for this document. Once received, it wraps the received document in a T-SOAP document.

Otherwise, it does not wait and continues to the Receive completion step.

Deliver ack deliverAckSvc This step is only invoked if the task supports the reception acknowledgment notification.

It delivers the T-SOAP document generated by the Receive ack step to the sender specified as model input.

X

Receive completion

receiveCompletionSvc If the task supports the completion notification, this step waits for this document. Once received, it wraps the received document in a T-SOAP document.

Otherwise, it does not wait and marks the model instance as successfully completed.

Deliver completion

deliverCompletionSvc This step is only invoked if the task supports the completion notification.

X




It delivers the T-SOAP document generated by the Receive completion step to the sender specified as model input.





Handle timeout


Handle error



- There is an integration task that cannot be achieved using the other standard models, like integration with an external HRMS.

- The sender is able to send a synchronous web-service request and analyze the returned response.

- The sender is able to send a T-SOAP request using the specifics related to the WS-TASK management (i.e., to set the task identifier in a predetermined XML tag)


- Automated on-boarding Tasks: As part of an on-boarding process, a new employee may need a phone line, a mailbox or require the payroll to create an employee account, the system network administrator to create



a login account, etc. While some of these activities might be instantiated by sending an email to the responsible persons, some others should be automated in order to streamline the on-boarding process.

- Preconfigured Command Processing: A customer needs to start the execution of a preconfigured integration process on an “on-demand” basis rather than on a scheduled basis (see also the WS-CMD-PROC model). In this case, the customer does not send the integration request for the integration process but rather references a command identifier that contains the integration request to be processed (not yet implemented).


4.6.5.1 EXTERNAL_TASK

The EXTERNAL_TASK EventID is associated to the Automated on-boarding Tasks Business Use Case. In the Taleo Onboarding application, the user invokes the list of the tasks currently registered on the Integration Framework for a given customer. From the returned list, it selects which task(s) to use in its on-boarding internal process. During the on-boarding process, a request document is sent to the Integration Framework with the EXTERNAL_TASK EventID. Because the Taleo Onboarding application has registered itself as a listener for this event, a WS-TASK model instance starts and delivers the stripped request document to the module implementing the task. If the implementation is able to notify an acknowledgment/completion document, the model waits for it, otherwise completes the transaction successfully.

The way the package or module finally implements the task (after the models delivered the request document) is abstract to the WS-TASK model and to the Taleo Onboarding application itself; the model therefore has no knowledge about how the task is implemented. This provides a lot of flexibility to the integration consultant for implementing the future needs of the on-boarding processes.

4.6.6 Handling new scenarios As opposed to the other models in the Taleo Framework, new scenarios might necessarily need the creation of new events to implement new integration tasks. This is due to the flexibility to “plug-in” new implementation modules to implement new integration tasks.

In order to make a new task implementation available from the WS-TASK model, you have to register it. Once registered, the user should find the new task identifier by invoking the list of current implemented tasks.

For more information on how to un/register a task or retrieve the list of already implemented tasks in the WS-TASK model, see Built-in Task Registering Services Reference on page 55.



4.6.6.1 Built-in Task Registering Services Reference

taleo.is.framework.wstask.core.v1.handler:registerTask TaleoFrameworCoreV1. Registers a task implementation to the Taleo Framework to be used from the WS-TASK model.

Input Parameters clientId String (optional). Specifies the customer name for which this task

applies.

applicationType String (optional). Specifies the application type for which this task applies.

Valid values are the listeners’ names configured in the Taleo Framework. Built-in values are:

Onboarding CUSTOMER PERM Contingent

If more listeners are added to the Taleo Framework, these values will also be valid input.

definitions Document List. List of definitions that apply for this task.

Note: At least a task definition for the en_US locale is mandatory.

Key Description

locale String. Specifies the language locale corresponding to this definition.

definition Document. Definition that describes this task in this locale.

Key Description

name String. Specifies the name of this task.

description String. Specifies a short description of this task.

canAckReception String. Specifies whether this task can notify the WS-TASK model once the target system receives the request.

Valid values are:

true false

receptionTimeout String (optional). Specifies the lapse of time the WS-TASK model should wait for the reception acknowledgment before timing out. Useless if canAckReception is set to false.

canAckCompletion String Specifies whether this task can notify the WS-TASK model once completed.

Valid values are:

true false

completionTimeout String (optional). Specifies the lapse of time the WS-TASK model should wait for the task completion notification before timing out. Useless if canAckCompletion is set to false.



callbackSvc String. Specifies the fully-qualified name of the webMethods service to invoke when this task should be processed. For example:

taleo.is.framework.wstask.main.impl:runTask

sendRequestAs String (optional). Form in which the implementation module of this task wants to receive the document request.

Sets to… To…

bytes Default. Send the body of a request document as a byte[ ]. Use this option if the body will be used as input to a service that operates on whole XML documents.

string Send the body of a request document as a java.lang.String. Use this option if the body will be used as input to a service that operates on whole XML documents.

Similar to the bytes value option, but this object assumes the document request is encoded using the UTF-8 encoding and builds a String from the body of the request.

stream Send the body of a request document as a java.io.InputStream. Use this option if the document will be used as input to a service that can process documents incrementally.

Output Parameters uuid String. The unique task identifier assigned to this task

registration.

Keep track of the task identifier because it is required to unregister the task at later time.



taleo.is.framework.wstask.core.v1.handler:unregisterTask TaleoFrameworCoreV1. Unregisters a task implementation previously registered in the Taleo Framework. Once unregistered, the task implementation can no longer be used from the WS-TASK model.

Input Parameters id String. The unique task identifier to unregister. This identifier is

generated by the WS-TASK model while registering this task implementation.

Output Parameters None.



taleo.is.framework.wstask.core.v1.handler:getTaskList TaleoFrameworCoreV1. Returns the list of currently registered task implementations.

Note: This service used to be invoked by a web-service request, not directly. See annotations for how to retrieve the list of currently registered task implementations using a SOAP request.

Input Parameters clientId String. Specifies the customer name to use when returning the

list of task implementations.

locale String (optional). Specifies the locale to use when returning the task name and description.

If the specified locale was not defined while registering the task implementation, the task name and description will be returned using the locale en_US.

Output Parameters tasks Document List The list of task implementations currently

registered in the WS-TASK model.

Key Description

identifier String. The identifier of this task implementation.

name String. The name of this task implementation in the specified locale.

description String. The description of this task implementation in the specified locale.

acknowledgmentNotificationExpected Boolean. A flag indicating if the task implementation is able to acknowledge the reception of a task request.

acknowledgmentNotificationTimeout String. The lapse of time in milliseconds to wait for the reception acknowledgment before considering that the transaction has timed out.

completionNotificationExpected Boolean. A flag indicating if the task implementation is able to notify the completion of a task request.



completionNotificationTimeout String. The lapse of time in milliseconds to wait for the completion notification before considering that the transaction has timed out.

Usage Notes: This service should be accessed through a synchronous web service (that is, sending a SOAP request to the Taleo Framework HTTP/S gateway service named taleo.is.framework.core.v1.handler:receive).

To retrieve the list of the currently implemented tasks using a SOAP request, see “Appendix A: WS-TASK Web Service WSDL” on page 95.



4.7 WS-CMD-PROC – Command Processing

4.7.1 Model definition The WS-CMD-PROC model is a pre-configured processing command (or integration task). Commands (or integration tasks) are stored in customer configuration files.

With this model, the Integration Framework acts as a processor by:

- Retrieving some documents from an FTP drop box, an FTP server, or an operating system folder and storing them in temporary storage to ensure that no document is modified or deleted during the processing of the command.

- If no documents are found, the model completes

i. Either with success, if the command states that this is a valid situation.

ii. Either with warning, if the command states that this situation might occur but should be monitored.

iii. Either with error, if the command states that this situation should not occur.

- For each retrieved document, the model then



i. Publishes a specific EventID in order to trigger one or more Taleo business process models. After publishing the event, the model makes sure that at least one model instance has actually started (by waiting for a reception acknowledgment that all models implement).

ii. Waits for the acknowledged model instance completion notification: a model instance either completes with success, with warning(s), or with error(s).

iii. Processes the next document in the list.

- Once the model has processed all the retrieved documents, it completes

i. Either with success, if all started model instances completed with success.

ii. With warning, if at least one model instance completed with warning(s).

iii. With error, if at least one model instance completed with error(s).



Start startSvc This step generates an identifier specific to the transaction that all documents traversing this model instance will carry (used for correlation purposes).

Finally, it saves transactional data in the model runtime engine (GlobalData of the PRT) to ensure guaranteed delivery.

Process command

processCommandSvc This step extracts the command definition from the request.

It then retrieves the documents from the location specified in the command definition.

Finally, it builds up an indexed table of the retrieved documents and stores each of these documents in the Taleo Framework Repository.

X

No file to process

noFileToProcessSvc This method is invoked when no files were found at the location specified by the



Step Name Service Name Description Rcommand definition. Depending on the error handling rules defined in the command definition, it either marks the transaction as completed with success, completed with warnings, or throws an exception.

Publish requests

deliverSvc This step publishes the documents according to the processing mode (either each document sequentially or all documents in parallel). By publishing the request, the model sets the EventID of the document to the one specified in the command definition.

If the processing mode is sequential, it then waits for the first acknowledgement of a model instance (more than one model instance might be triggered by the published document if more than one application listener subscribes to the same EventID associated to this command).

X

Wait for response(s)

ackDoneSvc This step waits for the started model instances of each published document to complete. The model instances complete either with success, with warning, or with error.

It then updates the indexed table of documents with the associated model completion result.

Ack command reception


Command completed

ackAllDoneSvc This step publishes a message acknowledging that



Step Name Service Name Description Rwith success

the transaction was successfully completed. This message refers to the instance identifier created in the Start transaction step.

Handle timeout

timeoutHandlerSvc Depending on the command definition, this step either throws an error, indicating that the model timed out, or it publishes a warning message. This message refers to the instance identifier created in the Start transaction step.

Handle error


X

Handle files in error

processFilesInErrorSvc Depending on the command definition, this step either throws an error, indicating that at least one document (or file) processing failed, or it publishes a warning message. This message refers to the instance identifier created in the Start transaction step.

X

Retry limit exceeded

handleRetriesExceededSvc A process instance of WS-CMD-PROC has a specific resubmission management that allows only documents whose processing failed to be resubmitted. If the model reaches the maximum number of allowed resubmissions, this step throws an error.




- An integration task must be processed according to a specific schedule.

- The user cannot or does not want to send the request directly using the HTTP/S protocol but only using an FTP drop box.

- The user wants the Integration Framework to store the exact request document locally that responds to a specific integration need (or even does not know the content of this request).


- CSV Scheduled Import: The customer sends document(s) in a generic CSV format to an FTP drop box that the Integration Framework polls according to a specific schedule; the customer expects the import results in the same generic CSV format.

- CSV Scheduled Export: According to a specific schedule, the Integration Framework executes a predefined Selection Query (stored locally on the Integration Server) against the customer application hosted by Taleo; the customer expects the results in a generic CSV format.

- System to system synchronization: A request is sent that extracts some data from a system and synchronizes this data with another system.

4.7.5 Built-in scenarios Unlike other models, there are no built-in scenarios in the form of events proposed by the WS-CMD-PROC model.

The user handles scenarios by configuring integration commands (or integration tasks). There are currently no default commands because these command configurations are stored on a per-customer basis in the customer’s associated configuration file.

For more information about customizing new scenarios, refer to the next section.

4.7.6 Handling new scenarios

4.7.6.1 Commands

As mentioned in the previous section, the user configures a new command to respond to a new scenario (or integration need that applies to the WS-CMD-PROC model).

While defining the command, the user specifies the way the model should acquire the documents to process. For example, these documents could be retrieved from an FTP server (or Taleo drop boxes); files located on the local file system; or files located on a NFS mapped directory.

The user can also define a retrieval pattern and a sequencing to filter and order the documents to retrieve. For example, the user may want to retrieve the XML files ending with the “workflowlookup” characters first, then the XML files ending with “candidates” characters; the user would then specify a first input file pattern “*workflowlookup.xml” (seq. #1), then another input file “*candidates.xml” (seq. #2) as selection criteria. Each selection criteria specifies which EventID should be used to process the matching retrieved files.



The user then specifies how the model should deliver the response document that the sender might expect (depending on the invoked business process model, see below). For example, the model may deliver the response document(s) to an FTP server (or Taleo drop box); may post the document to an HTTP server; or may send it by email.

While delivering the document, the model’s default behavior is to generate a unique document filename. The user can override this behavior by defining a filename pattern to be used for delivered documents: the pattern can specify a filename prefix, a filename suffix, a timestamp suffix, and a filename extension.

Finally, the user specifies how long it expects the command processing to last. This lapse of time can be absolute (the user specifies the time and date when the command processing should be completed), or relative (the user specifies a period of time after which the command processing should be completed).

For more information on how to configure a new command using XML configuration files, see “Customer configuration” on page 84.

4.7.6.2 Scheduled Integration Tasks

In addition, configured commands can be scheduled using the Taleo Framework Web Manager. This lets the Taleo Framework run specific commands repetitively, according to a specific schedule. As opposed to direct HTTP/S customer requests, the model instance initiator is the Integration Server Scheduler, not the customer himself.

By scheduling a command, the user specifies a customer identifier, selects the command to execute from the list of configured commands, and specifies a schedule.

For more information on how to schedule commands using the Taleo Framework Web, see “Creating a new Scheduled Integration Task” on page 17.



5 Planning a new Integration Process If you are about to define a new integration business process, the Taleo Framework will most probably cover your need. If not, address your needs to the Integration Development team: the Framework team will review the need and may address it in upcoming versions.

This chapter should provide you with a roadmap to plan and configure new business processes.

5.1 Identify your Needs The questions you first have to ask yourself are:

- What are the requirements of my integration process?

- Does any model already implement my needs? If yes, all you have to do is to configure the customer configuration file to your requirements. If not, one of the models might need some customization to implement your needs.

To determine the suitable model for your integration needs, follow the workflow below:



Transformation needed?

WS-IS

Sync. with 2 systems involved

yes

no

Sender expects response

WS-EXTRACT-

SYS

WS-SYSno

WS-EXTRACT

no

yes

yes

no

Customer/System specific

integration task?

WS-TASK

yes

Additionally, to help you to identify which model is most suited for your needs, the following matrix identifies the features and limitations of the Taleo Framework models:



Feature WS-IS WS-EXTRACT WS-SYS WS-EXTRACT-SYS

WS-TASK WS-CMD-PROC

No transformation required

X X* X* N/A*

Request transformation required

X X X N/A*

Response transformation required

X X N/A*

PGP encryption involved

X X X N/A*

PGP decryption involved

X X X N/A*

Must be scheduled X

Data acquisition required

X

Request must be pre-sourced X

Asynchronous response expected

X X X N/A*

Asynchronous response impossible

X X X N/A*

Customer or external system specific implementation required

X N/A*

Transaction should fail on business errors

X X N/A*

Once you’ve identified a matching model, see the “When to use this model” section of the selected model to make sure all the associated conditions also apply to your integration process.

5.2 Code your Custom Transformations (optional) Once the model corresponding to your needs has been identified, and the standard offering does not satisfy your needs, you have to customize it. This is especially true for any model involving transformation steps.

The architecture of the Taleo Framework models let the user override virtually any default implementation service associated to a model step. However, in most cases, you will only have to consider the customization of the transformation steps, if any are involved.

The Taleo Framework currently offers four ways to customize transformation steps:



- transformXSL: A service that applies a simple XSL transformation to a request document. The service expects the XSL file as the input parameter and outputs the result of the XSL transformation.

- transformXSLRecords: A service that applies an XSL transformation on each sub record found in the request document. The service expects some parameters in order to indicate

i. How to identify the XML path to the sub record from the request document.

ii. The XSL to apply to each record.

iii. The XSL to apply to the template header and footer of the response document (if any).

- transformCustom: A service that wraps the invocation of another customizable transformation service. The service expects the transformation service name as the input parameter and outputs the response document returned by this service.

- doNothing: AS service that does nothing but allows a user to bypass a transformation step, if (s)he wishes not to apply any transformation on this step. For example, if a WS-EXTRACT model is used, and the user wants to transform the response document only but not the request document, the user could customize the transform request step to invoke this service.

Additionally, these transformation steps allow the execution of one pre-processing and one post-processing service. These services can be useful to add some processing before or after the transformation service (i.e., examine the content of the document to be transformed and eventually take action, or send an email of the document once transformed).

To use and customize these services, in the context of a specific scenario (EventID), the user creates a routing entry in the configuration file associated to a specific listener. A listener is an entity in the Taleo Framework that subscribes to different events (the EventIDs) in order to start new model instances. For each event, the user defines in the routing entry which service to invoke to which model step and can specify a list of parameters (a collection of name/value set).

For more information on the creation of routing entry using the descriptive XML language, see “Routing configuration” on page 84.

For in-depth documentation of the transformation services, refer to the next section.



5.2.1 Built-in Transformation Services Reference

This section contains a detailed developer reference of the built-in transformation services of the Integration Framework.

For an example of how to use these transformation services in a concrete routing configuration, see Taleo Integration Framework Custom Use Cases.

5.2.1.1 taleo.is.framework.core.v1.model.defaultImpl:transformXSL

TaleoFrameworCoreV1. Applies an XSL transformation to a request document and returns the result of the transformation.

Input Parameters xslFilename String. Specifies the name of the XSL file to use for the

transformation. The name is relative to the path of the routing configuration file (referencing this service).

preProcessSvcName String (optional). Specifies the name of the webMethods service to invoke BEFORE transforming the document. The webMethods service must implement the transformSvc specification.

postProcessSvcName String (optional). Specifies the name of the webMethods service to invoke AFTER the document was transformed.

any parameter name to use as XSL parameter name

String (optional). Any parameter value you want to forward to the XSL transformer.


Usage Notes: Pre-processing and post-processing services

The webMethods pre- and post-processing services must be located in a loaded webMethods package, and must implement the taleo.is.framework.transformer.v1.spec:transformSpec specification. Example of such services can be found in the Custom Transformation Services section.

Large files

This service should not be used with large files, that is, request documents whose content is more than a few kilobytes. This limitation is due to the underlying XSL transformer, used by this service, that loads the whole document content in memory to apply the transformation. If the file is larger, you should consider using the taleo.is.framework.core.v1.model.defaultImpl:transformXSLRecords service instead.

XSL parameters

The model forwards to the XSL transformer a list of parameter values specified in the routing configuration file: for each specified parameter (name and value) the model creates an XSL parameter using the specified parameter name and sets its value with the specified parameter value.

Additionally, the model also forwards the following information to the XSL transformer as an XSL parameter:

- senderID: Contains the delivery identifier corresponding to the sender of the document to be transformed.



- receiverID: Contains the delivery identifier corresponding to the receiver of the document to be transformed.

- eventID: Contains the event identifier corresponding to the scenario currently being processed.

- bpID: Contains the model process identifier corresponding to the model name currently being processed.

- messageID: Contains a unique generated identifier if not already specified by any other parameter.

- currentRunDate: Only present if the event identifier corresponding to the scenario currently being processed is configured to use the LastRunDate feature; it contains the date of the current query execution (as defined by the Integration Framework).

- lastRunDate: Only present if the event identifier corresponding to the scenario currently being processed is configured to use the LastRunDate feature; it contains the date of the last query execution (as defined by the Integration Framework).

If a parameter value contains @UUID@ in its specified value, a unique generated identifier will replace this @UUID@.

Special T-SOAP XSL parameters

If the document request uses the T-SOAP format and contains SOAP headers in the namespace of Taleo Connect (“http://www.taleo.com/ws/integration/toolkit/2005/07”), the name of the headers are converted to XSL parameters; the name of each XSL parameter is built from the “itk_[SOAP header name]” format and its value is the SOAP header’s extracted value.

If the document request uses the T-SOAP format, it also adds an XSL parameter named conversationID. The value of the parameter depends on the presence of an optional SOAP header named ConversationID; if the SOAP header is found, the XSL parameter takes this value, otherwise it takes the mandatory SOAP header MessageID value.

Finally, if the document request uses the T-SOAP format, it adds an XSL parameter named relatesTo. Its value corresponds to the mandatory SOAP header MessageID of the initial document request. This enables tracking of T-SOAP conversation documents (both to be transformed and transformed documents).

See also: taleo.is.framework.core.v1.model.defaultImpl:transformXSLRecords

taleo.is.framework.core.v1.model.defaultImpl:transformCustom



5.2.1.2 taleo.is.framework.core.v1.model.defaultImpl:transformXSLRecords

TaleoFrameworCoreV1. Applies an XSL transformation to a request document and returns the result of the transformation. As opposed to the taleo.is.framework.core.v1.model.defaultImpl:transformXSL service that gently handles large files, that is, documents whose content is larger than a few kilobytes.

To achieve this, the internal XSL transformer uses a template file to generate the header and footer of the transformed document, and then applies an XSL transformation on each record element found in the request document. A record element is each element found in the request document whose parent node corresponds to a specific root element. The user can specify the name of this root element. Optionally, the user can also specify an XSL file to apply to the template file containing the header and the footer to append before and after the transformed records.

Input Parameters templateFilename String (optional). Specifies the name of the XML file to use as the

template for the transformation. The name is relative to the path of the routing configuration file (referencing this service).

Note: This template file contains a text that has a header and a footer that will be output before and after the transformation applied on each record. See also the xslFilename and rootTag parameters.

If the special tag “${DATA_PLACEHOLDER}“ is present in the template file content, it will separate the header from the footer (without the quotes). Otherwise, the entire content is interpreted as the header and no footer is output. See also the templateXslFilename parameter.

If not specified and templateXslFilename is specified, templateFilename is assumed to be an empty XML file.

If not specified and templateXslFilename is also not specified, templateFilename is assumed to be an empty string (“”).

templateXslFilename String (optional). Specifies the name of the XSL file to apply to the file specified by templateFilename. The name is relative to the path of the routing configuration file (referencing this service).

Note: Use an XSL template file if some tags need transformation in the header or the footer of the template file specified by templateFilename.

xslFilename String (optional). Specifies the name of the XSL file to use for the transformation. The name is relative to the path of the routing configuration file (referencing this service). If not specified, the service will echo each record without transforming them. See also the echoNoProlog parameter.

echoNoProlog String (optional). Flag indicating whether to omit the XML declaration (i.e., <?xml version="1.0" encoding="UTF-8"?>) in the echo transformation applied on each record. The XML declaration is omitted when set to true. Useless if an xslFilename is specified.

Valid values are:

true false



rootTag String (optional). Specifies the name of the root element tag to use as a parent node of the elements to be considered as records.

Caution: The service will search for this root element tag and discard any previous tags (both structure and content). Any element tag found under this root element tag will be considered a record, and the XSL transformation file specified as xslFilename will be applied to it.

preProcessSvcName String (optional). Specifies the name of the webMethods service to invoke BEFORE transforming the document. The webMethods service must implement the transformSvc specification.


any parameter name to use as XSL parameter name

String (optional). Any parameter value you want to forward to the XSL transformer.


Usage Notes: XSL parameters

The model forwards to the XSL transformer a list of parameter values specified in the routing configuration file: for each specified parameters (name and value) the model creates an XSL parameter using the specified parameter name and sets its value with the specified parameter value. When a XSL template file is used in addition to the record-based XSL file, both XSL files are provided with the following XSL parameters.

Additionally, the model also forwards the following information to the XSL transformer as an XSL parameter:

- senderID: Contains the delivery identifier corresponding to the sender of the document to be transformed.

- receiverID: Contains the delivery identifier corresponding to the receiver of the document to be transformed.

- eventID: Contains the event identifier corresponding to the scenario currently being processed.

- bpID: Contains the model process identifier corresponding to the model name currently being processed.

- messageID: Contains a unique generated identifier if not already specified by any other parameter.

- currentRunDate: Only present if the event identifier corresponding to the scenario currently being processed is configured to use the LastRunDate feature; it contains the date of the current query execution (as defined by the Integration Framework).

- lastRunDate: Only present if the event identifier corresponding to the scenario currently being processed is configured to use the LastRunDate feature; it contains the date of the last query execution (as defined by the Integration Framework).




Special T-SOAP XSL parameters

If the document request uses the T-SOAP format and contains SOAP headers in the namespace of Taleo Connect (“http://www.taleo.com/ws/integration/toolkit/2005/07”), the name of the headers are converted to XSL parameters; the name of each XSL parameter is built from the “itk_[SOAP header name]” format and its value is the SOAP header’s extracted value.

If the document request uses the T-SOAP format, it also adds an XSL parameter named conversationID. The value of the parameter depends on the presence of an optional SOAP header named ConversationID; if the SOAP header is found, the XSL parameter takes this value, otherwise it takes the mandatory SOAP header MessageID value.

Finally, if the document request uses the T-SOAP format, it adds an XSL parameter named relatesTo. Its value corresponds to the mandatory SOAP header MessageID of the initial document request. This enables tracking of T-SOAP conversation documents (both to be transformed and transformed documents).

See also: taleo.is.framework.core.v1.model.defaultImpl:transformXSL

taleo.is.framework.core.v1.model.defaultImpl:transformCustom



5.2.1.3 taleo.is.framework.core.v1.model.defaultImpl:transformCustom

TaleoFrameworCoreV1. Applies a custom transformation to a request document and returns the result of the transformation.

Input Parameters preProcessSvcName String (optional). Specifies the name of the webMethods service

to invoke BEFORE transforming the document. The webMethods service must implement the transformSvc specification.

transformSvcName String. Specifies the name of the webMethods service to invoke that will transform the document.


Any parameter name to use as XSL parameter name

String (optional). Any parameter value you want to forward to the custom transformation service.

Note: See the taleo.is.framework.transformer.v1.spec:transformSpec specification for more information on how the parameters are forwarded to the custom transformation service.


Usage Notes: The webMethods service must be located in a loaded webMethods package and must implement the taleo.is.framework.transformer.v1.spec:transformSpec specification.

See also: taleo.is.framework.transformer.v1.spec:transformSpec

taleo.is.framework.core.v1.model.defaultImpl:transformXSLRecords

taleo.is.framework.core.v1.model.defaultImpl:transformXSL



5.2.1.4 taleo.is.framework.core.v1.defaultImpl:doNothing

TaleoFrameworCoreV1. This service is not a real transformation service as it does absolutely nothing but echo the incoming document. Under some circumstances, the user may configure a custom scenario to use a Taleo Framework process model involving more than one transformation step (i.e., WS-EXTRACT) but does not want all these transformation steps to actually “transform” the document. For this purpose, the user should specify this service for the unneeded transformation steps.

Input Parameters None.




Built-in Custom Transformation Services Reference

Beside the built-in transformation services described in the previous section, you can extend the Framework by adding your custom transformation services. Such services could be a webMethods Java service or a webMethods Flow service.

Custom transformation services can be referenced in the transformSvcName parameter of the taleo.is.framework.core.v1.model.defaultImpl:transformCustom service, but also in the preProcessSvcName or postProcessSvcName parameters of any of the built-in transformation services referenced in the previous section.

5.2.1.5 taleo.is.framework.transformer.v1.spec:transformSpec

TaleoFrameworkTransformerV1. Specification for custom transformation services.

Input Parameters inputStream java.io.InputStream The InputStream object containing the document to be

transformed.

outputStream java.io.OutputStream The OuputStream object where to write the transformed document.

dynamicParams Document. A list of defined dynamic parameters determined at runtime (i.e., that could be needed to build the document XML transport envelope for the transformed document)

Key Description

bpID String. Contains the business process identifier of the document to be transformed.

eventID String. Contains the event identifier of the document to be transformed.

senderID String. Contains the sender identifier of the document to be transformed.

receiverID String (optional). Contains the receiver identifier of the document to be transformed.

messageID String (optional). Contains the message identifier to assign to the transformed document if “messageID” was specified as input parameter to the taleo.is.framework.core.v1.model.defaultImpl:transformCustom service

ProcessData Document. Contains the ProcessData of the model being currently processed. This allows to automatically trace errors and activity logs logged by the custom service with the model instance currently being processed.

itk_[SOAP header name]

String (optional). If the input document format is T-SOAP, it contains the value of the SOAP header (only if in the Taleo Connect Server namespace).

conversationID String (optional). If the input document format is T-SOAP, it contains the value of the ConversationID (if present) or the MessageID SOAP header (always present).

relatesTo String (optional). If the input document format is T-SOAP, it contains the value of the MessageID SOAP header (always present).

currentRunDate java.util.Date (optional). If the LastRunDate feature is used for the scenario (EventID), it contains the current run date of the current query using the Integration Framework’s own time



reference.

lastRunDate java.util.Date (optional). If the LastRunDate feature is used for the scenario (EventID), it contains the last run date of the current query using the Integration Framework’s own time reference.

fixedParams Document (optional). A list of user defined input parameters retrieved from the input parameters specified to the taleo.is.framework.core.v1.model.defaultImpl:transformCustom service.

Key Description

configPath String. Contains the absolute path to the files referred in the input parameters, if any specified

input parameter name

String. Input parameter value as defined by the taleo.is.framework.core.v1.model.defaultImpl:transformCustom service.



Usage Notes: The taleo.is.framework.core.v1.model.defaultImpl:transformCustom service expects the custom transformation service (either Java or Flow based) to write in the provided OutputStream object. Once the custom transformation service is executed, it will read this object and replace the current document request by this transformed document.

See also: taleo.is.framework.core.v1.model.defaultImpl:transformCustom



5.2.1.6 taleo.is.framework.transformer.v1.impl:transformFlatFile

TaleoFrameworkTransformerV1. A custom transformation service that searches and replaces configurable tokens in a flat file. You can configure the token to be replaced by either a fixed value or a variable value.

Input Parameters Refer to the taleo.is.framework.transformer.v1.spec:transformSpec specification.

Output Parameters Refer to the taleo.is.framework.transformer.v1.spec:transformSpec specification

Usage Notes: The service expects a fixed variable named ffMappingFile that refers to the filename (relative to the routing configuration file) where the mapping is configured (which tokens to replace with which values).

The mapping configuration file is in an XML format. You can create a new configuration file from the XSD schema file, using your favorite XML editor. The following example is used for the LastRunDate feature: <?xml version="1.0" encoding="UTF-8"?> <FFMapping version="1" xmlns="http://www.taleo.com/ns/transformer/flatfile/2006/02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" :schemaLocation="http://www.taleo.com/ns/transformer/flatfile/2006/02 transformer.flatfile.xsd"> <FFTokens> <FFToken name="@lastRunDate@" replaceByVariableName="$lastRunDate" dateFormat="yyyy-MM-dd" default="$currentRunDate"/> <FFToken name="@currentRunDate@" replaceByVariableName="$currentRunDate" dateFormat="yyyy-MM-dd"/> </FFTokens> </FFMapping>

The FFTokens section contains a list of FFToken elements, each referring to a “name” attribute (the token to search for in the incoming document) and either a “replaceByVariableName” or “replaceByValue” attribute, containing the value to replace with.

In the former case, the token found is replaced by the value of the variable name specified. In the latter case, the token found is replaced by the value specified (as-is).

A default value can optionally be specified to these attributes (if the variable value to replace with is unknown or null). The “default” attribute value can be a hard coded value or the value of a variable name: to specify a variable name, you must prefix the variable name with $.

A specific “dateFormat” attribute can also be optionally specified if the value to replace the token with is a date. If the variable to replace the token with is a date, the underlying internal object of the variable is java.util.Date. Use this attribute to apply a textual format to the Date object in the transformed document.

To wrap it up, here is the expected behavior of the service with the previous mapping configuration sample:

- Any occurrence of the “@lastRunDate@” token found in the incoming flat-file document will be replaced by the value of the “lastRunDate” variable (from the dynamicParams Document object submitted to the service, see taleo.is.framework.transformer.v1.spec:transformSpec). Because the underlying



internal Java object of the lastRunDate variable is of type java.util.Date, the format yyyy-MM-dd will be applied to its value and replaced in the transformed document. If value of the lastRunDate variable is null or missing, the value of the currentRunDate variable will be used (if existing).

- Any occurrence of the “@currentRunDate@” token found in the incoming flat-file document will be replaced by the value of the “currentRunDate” variable (from the dynamicParams Document object submitted to the service, see taleo.is.framework.transformer.v1.spec:transformSpec). Because the underlying internal Java object of the currentRunDate variable is of type java.util.Date, the format yyyy-MM-dd will be applied to its value and replaced in the transformed document. Note that no default variable is specified, which means that if the variable is missing or null, the replaced string will be empty (“”).

See also: taleo.is.framework.transformer.v1.spec:transformSpec taleo.is.framework.core.v1.model.defaultImpl:transformCustom



5.2.1.7 taleo.is.framework.transformer.v1.impl:transformXSL

TaleoFrameworkTransformerV1. Equivalent to the taleo.is.framework.core.v1.model.defaultImpl:transformXSL.service, in order to make it useable from a pre- or post-processing service.



Usage Notes: See the taleo.is.framework.core.v1.model.defaultImpl:transformXSL service for usage notes.

See also: taleo.is.framework.transformer.v1.spec:transformSpec taleo.is.framework.core.v1.model.defaultImpl:transformXSL



5.2.1.8 taleo.is.framework.transformer.v1.impl:transformXSLRecords

TaleoFrameworkTransformerV1. Equivalent to the taleo.is.framework.core.v1.model.defaultImpl:transformXSLRecords.service, implementing the taleo.is.framework.transformer.v1.spec:transformSpec specification, in order to make it useable from a pre- or post-processing service.


Output Parameters Refer to the taleo.is.framework.transformer.v1.spec:transformSpec specification.

Usage Notes: See the taleo.is.framework.core.v1.model.defaultImpl:transformXSL service for usage notes.

See also: taleo.is.framework.transformer.v1.spec:transformSpec taleo.is.framework.core.v1.model.defaultImpl:transformXSLRecords



5.2.1.9 taleo.is.framework.core.v1.model.defaultImpl:validateResults

TaleoFrameworkCoreV1. Service used by the LastRunDate feature implementing the taleo.is.framework.transformer.v1.spec:transformSpec specification.

It validates if business errors are present in the incoming document. If errors are present, the service can be configured to throw an error and, in any case, rolls back the LastRunDate for the current query, that is, the date used as the “LastRunDate” variable for the current query execution. By rolling back this value, resubmitting the current transaction will re-use the same LastRunDate it used for the first iteration.

This service is intended to be used as a pre-processing service to a transformation step, transforming the results received from a Taleo application (i.e., Professional, Onboarding, etc.).



Usage Notes: The service may have an optional Boolean fixed variable named failOnError indicating whether or not an exception should be thrown if a business error is detected in the input document. If the variable is not present, no error is thrown. The output document is not modified by the service (echoed as-is).

See also: taleo.is.framework.transformer.v1.spec:transformSpec



5.3 Configure the Framework 5.3.1 Customer configuration The customer configuration file lets you specify all the connectivity, cryptographic, and integration task information associated to a specific customer.

The administrator must first gather all this information. Once gathered, the user creates an XML file that he validates against the XML schema definition (configuration.xsd) found in the IS_install/IntegrationServer/packages/TaleoFrameworCoreV1/config directory.

For in-depth documentation on the customer XML configuration file, see the “Customer configuration” section in the “Taleo Integration Framework Administration Guide.”

Once the XML configuration file is valid, the administrator deploys it on the IS server, by using an FTP client or a shell session. The administrator must use one of the directories listed in the “watt.taleo.framework.config.paths” Taleo Framework property. Once uploaded, the administrator must login to the Taleo Framework GUI and reload the configuration files from the “Configuration” link (see “Reload Configuration Files” on page 22).

A message confirms the reload of the configuration was successful:

Note: The list of currently loaded files only appears in the popup window if the “watt.taleo.framework.config.listLoadedFiles” Taleo Framework property is set to true.

5.3.2 Routing configuration In order to customize the transformation steps of the WS-EXTRACT, WS-SYS, WS-EXTRACT-SYS and WS-TASK models, you have to create or edit the routing configuration file.

The routing configuration file specifies the service to invoke on which model steps, the input parameters to submit to the invoked service, and manages the version of different scenarios.

Because a transformation service usually maps some fields from a given format to another, the service implementation directly depends on the version of those formats. For example, assume your transformation must transform a Taleo Staffing NewHire entity into a Taleo Onboarding TalentMasterFile entity. Depending on the Staffing version and the Onboarding version a customer uses, the mapping might be different.



By default, routing entries specified in a routing configuration apply to any customer. Using the previous example, the mapping from a NewHire into a TalentMasterFile is generic and therefore applies to any customer.

However, in some situations, the mapping might also have to transform User Defined Fields (UDF) or other customer-specific entities.

For all these reasons, a routing entry specifies a source and a target application type of a specific version. This means that one scenario (EventID) might use different services or different service parameters, depending on the associated source and target versions. The Taleo Framework listener that subscribes to this EventID will first lookup all the matching routing entries and filter out all those that do not apply for the current customer. The listener will then use the closest matching routing entry to start the model instance that will use its corresponding routing information.

Finally, a listener might subscribe to a specific scenario (EventID) without creating a specific routing entry. The model associated to this EventID will then use its default implementation, if it’s supported. This is particularly true for the WS-IS model that does not use any transformation steps.

For in-depth documentation on the XML routing configuration file, see the “Routing configuration” section in the “Taleo Integration Framework Administration Guide.”

5.4 Trigger and Start the Process 5.4.1 Overview By default request documents should be sent to the Taleo Framework Gateway service named taleo.is.framework.core.v1.handler:receive. This service represents a single endpoint reference of the Integration Framework for both internal and external requests. This service can handle

- Synchronous SOAP requests to invoke web services hosted on the webMethods Integration Server. These documents are forwarded to the webMethods built-in SOAP RPC processor (http://ISServer:port/soap/rpc).

- Asynchronous requests not supported by the Taleo Framework (that used to be delivered to the Trading Network Gateway service). These documents are forwarded to the Trading Networks “as-is” (http://ISServer:port/wm.tn/receive).

- Asynchronous requests supported by the Taleo Framework. These documents are dispatched to the webMethods Broker.

However, there are business situations where the user cannot send documents directly to the Integration Framework and where the Integration Framework has to retrieve the documents by polling them from the customer site.

The following sections describe both situations.

5.4.2 Sending External Requests

5.4.2.1 Sending files in T-SOAP or RS-XML formats

You can either use an HTTP/S client to send document requests or an FTP client, if the webMethods Integration Server has an open FTP listening port.



For example, if the host name of the Integration Server is “ISServer” and the port number is 5555, the user could post his documents to the following HTTP URL:

http://ISServer:5555/invoke/taleo.is.framework.core.v1.handler/receive

If the user has access to an FTP port on the webMethods Integration Server, he could login to this FTP server and put the files in the following remote path:

/ns/taleo/is/framework/core/v1/handler/receive/

5.4.2.2 Sending files in other formats (CSV, HR-XML, etc…)

You can only use an HTTP/S client to send document requests using formats other than T-SOAP or RS-XML. This is because the service needs additional input parameters that the FTP protocol does not support.

Only using the additional input parameters, the Taleo Framework is able to correctly dispatch the proper scenario identifier (EventID) and thus to correctly start the proper business process model(s) associated to this identifier.

Here is the list of input parameters that you must submit by posting the document using the HTTP/S protocol:

- bpID: The business process identifier to use for this request document.

- senderID: The sender identifier that sends this document.

- receiverID (optional): The receiver identifier to whom the response document should be returned, if any.

- eventID (optional): The event identifier to use for this request document. For backwards compatibility towards IS 3.0 SP2, unless otherwise specified and only if the bpID specified is WS-IS, the WS-IS_DEFAULT EventID is used. In all other cases, the EventID is mandatory.

- contentString (optional): The content of the request document, instead of using the input stream of the HTTP request.

For example, if the host name of the Integration Server is “ISServer”, the port number is 5555, and the user wants to post a document to his Taleo Professional application containing only an SQ-XML request (unrecognized format) that the WS-EXTRACT model should process, the following URL could be used:

http://ISServer:5555/invoke/taleo.is.framework.core.v1.handler/receive?bpID=WS-EXTRACT&eventID=SQ_EXTRACT_CSV&senderID=CUSTOMER&receiverID=CUSTOMER_ZONE

5.4.3 Scheduling Internal Requests If the network infrastructure or the customer does not allow to send files directly to the Gateway service, a Taleo Framework user with administrative authority has to create a command and schedule it using the Taleo Framework Scheduler Page.

For more information on how to create a command in a customer configuration file and schedule it, see “Customer configuration” on page 84 and “Creating a new Scheduled Integration Task” on page 17.

Once the command is configured and scheduled in the Taleo Framework Scheduler, you are ready to monitor your process.



5.5 Monitor and Troubleshoot the Process 5.5.1 Monitoring with the WmMonitor GUI of webMethods IS The main monitoring of the Taleo Framework is available through the webMethods Monitor application. Among other uses, WmMonitor can be used to troubleshoot errors and resubmit failed model steps.

To access the webMethods Monitor application, append /WmMonitor to the root webMethods Integration Server URL. For example, if the hostname of your Integration Server is “ISServer”, the port number is 5555, the user could use the following URL:

http://ISServer:5555/WmMonitor Note: The user should have administrative authority to login to the webMethods Monitor

application. Once logged in, the user can see the recent activity of the process. The user may also filter the listed transactions by using the Search link.

For more information on the webMethods Monitor application, see the “webMethods Monitor Users Guide” available on the webMethods Advantage website.

By convention, any model instance has a generated custom identifier that starts with the EventID, followed by the “|” delimiter, then the customer identifier, followed by the “|” delimiter, and a unique transaction identifier, preceded by “uuid:”. For example, a request for the START_OB_PROCESS scenario (see page 43) and the customer UNIT_TEST_CLIENT_ID will generate a transaction identifier like this:

To see the transaction details, the user clicks on the CustomID link that opens the model instance page:



From the screenshot above, you can easily identify the path the model used and which steps were executed with success. If an error occurs during the model instance execution, the model instance is reported under the recent failed processes:



From the screenshot above, you can easily identify the path the model used and that the “ack transaction completed” step failed.



By scrolling down the Instance Details page, you see the Step Status table, which lists the execution status of the steps. The status of the “ack transaction completion” step indicates Failed. Click the step name link to see error details:

The user clicks on the resubmit button to retry the execution of the service associated to the failed step.

5.5.2 Monitoring transactions with the Framework GUI Once a model transaction is started, the user can monitor it using the webMethods Monitor application. However, problems may occur before the model transaction can even start. This could be a poorly formatted document or missing information required to dispatch the document to the intended BPM.

For this purpose, the Taleo Framework includes a transaction analysis tool that lists the documents currently stored in the Framework repository. The guaranteed delivery implemented by the Framework ensures that an acknowledged document is first stored in the repository. Should the dispatcher service fail or the broker have connectivity problems (that would prevent the framework to start a model instance as expected) the user can resubmit the document previously stored in the repository.

For more information on how to search for documents stored in the repository, see “Transactions Page” on page 24.



Another monitoring need could be a user who wants to check the last run date of a scheduled polling integration task.

For this purpose, the Taleo Framework has a Scheduler Page that lists the currently scheduled polling integration tasks (also referred to as commands) and indicates the next scheduled run of each task (and thus indirectly indicates when the task executed for the last time).

For more information on how to monitor the list of commands currently scheduled in the Taleo Framework, see “The Scheduler Page” on page 15.

5.5.3 Monitoring the Server Log of webMethods IS The Taleo Framework logs several kinds of information at different levels. The logging mechanism used by the Framework is tightly integrated with the webMethods Integration Server logging facilities.

Each log entry in the Server Log contains an error code followed by a meaningful text. The error code used has the following format:

TIF.xxxx.yyyyAa

Where

- TIF is an acronym for Taleo Integration Framework

- xxxx represents a numeric value indicating a message category. The possible categories are:

i. 0000: general framework message ii. 1000: repository message iii. 2x00: configuration message iv. 3000: routing message v. 4000: data acquisition message (polling) vi. 5000: transformation message vii. 6000: command processing message viii. 7000: cryptography message (encryption/decryption) ix. 8000: external task processing message

- yyyy represents a numeric value. Each message has a unique numeric value for its associated message category.

- Aa represents a character optionally followed by a numeric value, indicating the IS log level associated to the message. The possible values are:

i. C: critical message (IS log level 0) ii. E: error message (IS log level 1) iii. W: warning message (IS log level 2) iv. I: information message (IS log level 3) v. D: debug message (IS log level 4) vi. V1: Verbose1 message (IS log level 5) vii. V2: Verbose2 message (IS log level 6) viii. V3: Verbose3 message (IS log level 7) ix. V4: Verbose4 message (IS log level 8) x. V5: Verbose5 message (IS log level 9)



xi. V6: Verbose6 message (IS log level 10)

The IS log level associated to an error code determines whether the message should be logged in the IS Server Log. The message will only appear in the IS Server Log if the current log level of your Integration Server is lower or equal to the log level associated to this error message.

Here are some error code examples to illustrate this:

- TIF.7000.0001C the log level associated is C-Critical, the message will always be logged, whatever the current IS Server log.

- TIF.0000.0010D the log level associated is D-Debug, the message will not be logged if the IS Server log is C-Critical, E-Error, W-Warning or I-Information. For any other log level, the message will be logged.

- TIF.0000.0019V3 the log level associated is V3-Verbose3, the message will be logged only if the IS Server log is V3-Verbose3, V4-Verbose4, V5-Verbose5 or V6-Verbose6.

Note: The Taleo Framework follows the same logging rules and error code format as the webMethods Integration Server.

For more information about the logging and monitoring functionalities of webMethods integration platform, see the “webMethods Integration Platform Logging and Monitoring Guide 6.1”.

5.5.4 Monitoring errors and warning with HP OVO To support the production teams, the Taleo Framework is tightly integrated with the existing HP OpenView Agent, developed for webMethods since IS 3.0 SP2.

Any model instance or service that fails or completes with warnings will generate an entry in the OVO agent.

5.5.4.1 Warnings

When a warning is issued within the Taleo Framework, a dedicated listener catches the warning and generates an entry in the logging database so that the OVO agent can later retrieve it.



The OVO agent returns the following when the Taleo Framework logs a warning:

<Error> <Timestamp>2006-01-03T12:05:12.765-05:00</Timestamp> <TransactionID>EXEC-CMD|CMD_PROC_SYS_TST_ID|NO_FILE_TO_PROCESS_FTP_SEND_WARNING |uuid:197b8d007c7b11da99b7f0082f3bb129</TransactionID> <TransactionType>WS-CMD-PROC</TransactionType> <ClientID>CMD_PROC_SYS_TST_ID</ClientID> <ErrorLevel>WARNING</ErrorLevel> <ErrorType>TASK-PROCESSING</ErrorType> <AdditionalInfos> <Info description="ComponentName">WM</Info> <Info description="InternalInfo">no file to process</Info> <Info description="InternalInfoDescription">Step with warning (name)</Info> <Info description="BriefMessage">[TIF.6000.0012C] Task-Processor error : no file found for processing</Info> <Info description="FullMessage">See warnings details in WmMonitor: http://qcdvin04.dev.rsft.net:5155/WmMonitor/inst_details.dsp?instanceID=197b8d007c7b11da99b7f0082f3bb129</Info> </AdditionalInfos> </Error>

The ErrorLevel section identifies the reported event is a warning, not an error.

The ErrorType section classifies the warning according to the error code associated to the warning. In the example above, 6000 is associated to the TASK-PROCESSING type (command processing).

The BriefMessage section provides a textual description of the error code associated to the warning.

The FullMessage section contains a link, that the user can copy and paste directly in a browser. This link opens the exact model instance that generated the warning.

5.5.4.2 Errors

When an error is thrown within the Taleo Framework, a dedicated listener catches the error and generates an entry in the logging database so that the OVO agent can later retrieve it.

The OVO agent returns the following when the Taleo Framework logs an error:

<Error> <Timestamp>2005-12-19T10:49:33.644-05:00</Timestamp> <TransactionID>WORKER_CANDIDATE_CONVERSION|SLABARRE_ID |uuid:0864e41070a711daa7769b5db8b2474b</TransactionID> <TransactionType>WS-EXTRACT</TransactionType> <ClientID>SLABARRE_ID </ClientID> <ErrorLevel>HIGH</ErrorLevel> <ErrorType>CONFIGURATION</ErrorType> <AdditionalInfos> <Info description="ComponentName">WM</Info> <Info description="InternalInfo">deliver transformed request</Info> <Info description="InternalInfoDescription">Last failed step (name)</Info> <Info description="BriefMessage">[TIF.2000.0004C] Configuration error : delivery or retrieval method does not exist.</Info> <Info description="FullMessage">See error details in WmMonitor: http://qcdvin04.dev.rsft.net:5155/WmMonitor/inst_details.dsp?instanceID=0864e41070a711daa7769b5db8b2474b</Info> </AdditionalInfos> </Error>



The ErrorLevel section identifies the reported event is an error, not a warning (thus HIGH).

The ErrorType section classifies the error according to the error code associated to the error. In the example above, 2000 is associated to the CONFIGURATION type.

The BriefMessage section provides a textual description of the error code associated to the error.

The FullMessage section contains a link that the user can copy and paste directly in a browser. This link opens the exact model instance that threw the error.



Appendix A: WS-TASK Web Service WSDL Copy and paste the following WSDL in any SOAP compliant client to generate a SOAP request that invokes the list of implemented tasks currently registered in the WS-TASK model. <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://localhost/taleo.is.framework.wstask.core.v1.handler" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdns1="http://localhost/taleo/is/framework/wstask/core/v1/handler/getTaskList" targetNamespace="http://localhost/taleo.is.framework.wstask.core.v1.handler" name="taleo_is_framework_wstask_core_v1_handler"> <wsdl:types> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://localhost/taleo/is/framework/wstask/core/v1/handler/getTaskList" xmlns:tns="http://localhost/taleo/is/framework/wstask/core/v1/handler/getTaskList" xmlns:SOAP_ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <xsd:import namespace="http://schemas.xmlsoap.org/soap/encoding/"/> <xsd:complexType name="__getTaskListInput"> <xsd:sequence> <xsd:element name="clientID" nillable="true" type="xsd:string"/> <xsd:element name="locale" nillable="true" type="xsd:string" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="__getTaskListOutput"> <xsd:sequence> <xsd:element name="tasks" nillable="true" type="tns:ArrayOf__Task"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="__Task"> <xsd:sequence> <xsd:element name="identifier" nillable="true" type="xsd:string"/> <xsd:element name="name" nillable="true" type="xsd:string"/> <xsd:element name="description" nillable="true" type="xsd:string"/> <xsd:element name="acknowledgmentNotificationExpected" nillable="true" type="xsd:anyType"/> <xsd:element name="acknowledgmentNotificationTimeout" nillable="true" type="xsd:duration"/> <xsd:element name="completionNotificationExpected" nillable="true" type="xsd:anyType"/> <xsd:element name="completionNotificationTimeout" nillable="true" type="xsd:duration"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ArrayOf__Task"> <xsd:complexContent> <xsd:restriction base="SOAP_ENC:Array"> <xsd:attribute ref="SOAP_ENC:arrayType" wsdl:arrayType="tns:__Task[]"/> </xsd:restriction> </xsd:complexContent> </xsd:complexType> </xsd:schema> </wsdl:types> <wsdl:message name="_getTaskListInput"> <wsdl:part name="clientID" type="xsd:string"/> <wsdl:part name="locale" type="xsd:string"/> </wsdl:message> <wsdl:message name="_getTaskListOutput"> <wsdl:part name="tasks" type="wsdns1:ArrayOf__Task"/> </wsdl:message> <wsdl:portType name="taleo_is_framework_wstask_core_v1_handlerPortType">



<wsdl:operation name="getTaskList"> <wsdl:input message="tns:_getTaskListInput"/> <wsdl:output message="tns:_getTaskListOutput"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="taleo_is_framework_wstask_core_v1_handlerBinding" type="tns:taleo_is_framework_wstask_core_v1_handlerPortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="getTaskList"> <soap:operation/> <wsdl:input> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/taleo.is.framework.wstask.core.v1.handler/taleo.is.framework.wstask.core.v1.handler"/> </wsdl:input> <wsdl:output> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/taleo.is.framework.wstask.core.v1.handler/taleo.is.framework.wstask.core.v1.handler"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="taleo_is_framework_wstask_core_v1_handlerService"> <wsdl:port name="taleo_is_framework_wstask_core_v1_handlerPort0" binding="tns:taleo_is_framework_wstask_core_v1_handlerBinding"> <soap:address location="http://[hostname]:[port]/invoke/taleo.is.framework.core.v1.handler/receive"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

Note: Replace the [hostname] and [port] placeholders with the actual Integration Server hostname and port.

A typical SOAP request looks like this:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:getTaskList xmlns:m="http://localhost/taleo.is.framework.wstask.core.v1.handler/taleo.is.framework.wstask.core.v1.handler" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <clientID xsi:type="xsd:string">[clientID]</clientID> <locale xsi:type="xsd:string">US_en</locale> </m:getTaskList> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Note: Replace the [clientID] placeholder with a valid customer identifier configured in the Taleo Framework.

For more information about the WS-TASK model and more specifically about the getTaskList built-in service, see “taleo.is.framework.wstask.core.v1.handler:getTaskList” on page 58.



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 complete 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


http://www.w3.org/

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

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


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

The objective is to normalize the integration platform by grouping common business 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 Professional applications v6.1.0 (and upper versions) as well as in other Taleo applications (Onboarding, Contingent, etc.) for data integration.


taleo integration framework

Documents