This chapter describes how to run and schedule integration processes.
This chapter includes the following sections:
An execution takes place when an integration task needs to be performed by Oracle Data Integrator. This integration task may be one of the following:
An operation on a model, sub-model or a datastore, such as a customized reverse-engineering, a journalizing operation or a static check started from the Oracle Data Integrator Studio
The execution of a design-time object, such as an interface, a package or a procedure, typically started from the Oracle Data Integrator Studio
The execution of a run-time scenario or a Load Plan that was launched from the Oracle Data Integrator Studio, from a command line, via a schedule or a web service interface
Oracle Data Integrator generates the code for an execution in the form of a session or in the from of a Load Plan run if a Load Plan is executed.
A run-time Agent processes this code and connects to the sources and targets to perform the data integration. These sources and targets are located by the Agent using a given execution context.
When an execution is started from Oracle Data Integrator Studio, the Execution Dialog is displayed. This dialog contains the execution parameters listed in Table 20-1.
Table 20-1 Execution Parameters
| Properties | Description |
|---|---|
|
Context |
The context into which the session is started. |
|
Agent |
The agent which will execute the interface. The object can also be executed using the agent that is built into Oracle Data Integrator Studio, by selecting Local (No Agent). |
|
Log Level |
Level of logging information to retain. All session tasks with a defined log level lower than or equal to this value will be kept in the Session log when the session completes. However, if the object execution ends abnormally, all tasks will be kept, regardless of this setting. |
|
Simulation |
Check Simulation if you want to simulate the execution and create an execution report. Refer to Section 20.10, "Simulating an Execution" for more information. |
This section describes the session lifecycle. See Section 14.1, "Introduction to Load Plans" for more information on Load Plan runs and the Load Plan life cycle.
The lifecycle of a session is as follows:
An execution request is sent to the agent, or the agent triggers an execution from a schedule.
Note that if the execution is triggered from Oracle Data Integrator Studio on a design-time object (interface, package, etc.), Studio pre-generates in the work repository the code for the session before sending the request. If the execution is started from a scenario, this phase is not necessary as the scenario already contains pre-generated code.
The agent completes code generation for the session: It uses the context provided to resolve the physical information such as data server connections and fully qualified tables names. This resulting code is written into the work repository as a session in Waiting status.
The agent initializes the connections to the source and target data servers that are required for the execution of the session.
The agent acknowledges the execution request. If the execution was started from the Studio, the Session Started Dialog is displayed.
The agent executes each of the tasks contained in this session, using the capabilities of the database servers, operating systems, or scripting engines to run the code contained in the session's tasks.
While processing the session, the agent updates the execution log in the repository, reports execution statistics and error messages.
Once the session is started, you can monitor it in the log, using for example Operator Navigator. Refer to Chapter 21, "Monitoring Integration Processes" for more information on session monitoring.
When the session completes, tasks are preserved or removed from the log according to the log level value provided when starting for this session.
Note:
A Session is always identified by a unique Session Number (or Session ID). This number can be viewed when monitoring the session, and is also returned by the command line or web service interfaces when starting a session.When starting an execution from other locations such as a command line or a web service, you provide similar execution parameters, and receive a similar Session Started feedback. If the session is started synchronously from a command line or web service interface, the command line or web service will wait until the session completes, and provide the session return code and an error message, if any.
Interfaces, procedures, and packages are design-time objects that can be executed from the Designer Navigator of Oracle Data Integrator Studio:
For more information on interfaces execution, refer to Section 11.3.8, "Execute the Integration Interface".
For more information on procedures execution, refer to Section 12.1.3, "Using Procedures".
For more information on packages execution, refer to Section 10.5, "Running the Package".
For more information on model operations, refer to Section 5.2, "Creating and Reverse-Engineering a Model", Section 5.6, "Checking Data Quality in a Model" and Section 7.2, "Setting up Journalizing".
Scenarios can be executed in several ways:
From a Web Service. See Section 20.11.2, "Executing a Scenario Using a Web Service" for more information.
From ODI Console. See Section 22.2.3, "Managing Scenarios and Sessions".
Note:
Before running a scenario, you need to have the scenario generated from Designer Navigator or imported from a file. Refer to Chapter 13, "Working with Scenarios" for more information.You can start a scenario from Oracle Data Integrator Studio from Designer or Operator Navigator.
To start a scenario from Oracle Data Integrator Studio:
Select the scenario in the Projects accordion (in Designer Navigator) or the Scenarios accordion (in Operator Navigator).
Right-click, then select Execute.
In the Execution dialog, set the execution parameters. Refer to Table 20-1 for more information. To execute the scenario with the agent that is built into Oracle Data Integrator Studio, select Local (No Agent).
Click OK.
If the scenario uses variables as parameters, the Variable values dialog is displayed. Select the values for the session variables. Selecting Latest value for a variable uses its current value, or default value if none is available.
When the agent has started to process the session, the Session Started dialog appears.
You can start a scenario from a command line.
Before executing a scenario from a command line, read carefully the following requirements:
The command line scripts, which are required for performing the tasks described in this section, are only available if you have installed the Oracle Data Integrator Standalone Agent. See the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator for information about how to install the Standalone Agent.
To use this command the connection to your repository must be configured in the odiparams file. See Chapter 4, "Managing Agents" for more information.
When starting a scenario from a command line, the session is not started by default against a remote run-time agent, but is executed by a local Java process started from the command line. This process can be aborted locally, but cannot receive a session stop signal as it is not a real run-time agent. As a consequence, sessions started this way cannot be stopped remotely.
This process will be identified in the Data Integrator log after the Local Agent name. You can change this name using the NAME parameter.
If you want to start the session against a run-time agent, you must use the AGENT_URL parameter.
To start a scenario from a command line:
Change directory to the /agent/bin directory of the Oracle Data Integrator installation.
Enter the following command to start a scenario.
On UNIX systems:
./startscen.sh <scenario_name> <scenario_version> <context_code> [<log_level>] [-AGENT_URL=<remote_agent_url>] [-NAME=<local_agent_name>] [-SESSION_NAME=<session_name>] [-KEYWORDS=<keywords>] [<variable>=<value>]*
On Windows systems:
startscen.bat <scenario_name> <scenario_version> <context_code> [<log_level>] [-AGENT_URL=<remote_agent_url>] ["-NAME=<local_agent_name>"] ["-SESSION_NAME=<session_name>"] ["-KEYWORDS=<keywords>"] ["<variable>=<value>"]*
Note:
On Windows platforms, it is necessary to "delimit" the command arguments containing "=" signs or spaces, by using double quotes. The command call may differ from the Unix command call. For example:On Unix
./startscen.sh DWH 001 GLOBAL SESSION_NAME=MICHIGAN
On Windows
startscen.bat DWH 001 GLOBAL "SESSION_NAME=MICHIGAN"
Table 20-2 lists the different parameters, both mandatory and optional. The parameters are preceded by the "-" character and the possible values are preceded by the "=" character. You must follow the character protection syntax specific to the operating system on which you enter the command.
Table 20-2 Startscen command Parameters
| Parameters | Description |
|---|---|
|
|
Name of the scenario (mandatory). |
|
|
Version of the scenario (mandatory). If the version specified is -1, the latest version of the scenario is executed. |
|
|
Code of the execution context (mandatory). |
|
|
Level of logging information to retain. This parameter is in the format Example: |
|
|
URL of the run-time agent that will run this session. If this parameter is set, then |
|
|
Agent name that will appear in the execution log for this session, instead of Note that Using an existing physical agent name in the
It is recommended to use a If you want to start a session on a given physical agent, you must use the |
|
|
Name of the session that will appear in the execution log. |
|
|
List of keywords attached to this session. These keywords make session identification easier. The list is a comma-separated list of keywords. |
|
|
Allows to assign a This parameter can be repeated to assign several variables. Do not use a hash sign (#) to prefix the variable name on the startscen command line. |
Any session that has encountered an error, or has been stopped by the user can be restarted.
Oracle Data Integrator uses JDBC transactions when interacting with source and target data servers, and any open transaction state is not persisted when a session finishes in error state. The appropriate restart point is the task that started the unfinished transaction(s). If such a restart point is not identifiable, it is recommended that you start a fresh session by executing the scenario instead of restarting existing sessions that are in error state.
Only sessions in status Error or Waiting can be restarted. By default, a session restarts from the last task that failed to execute (typically a task in error or in waiting state). A session may need to be restarted in order to proceed with existing staging tables and avoid re-running long loading phases. In that case the user should take into consideration transaction management, which is KM specific. A general guideline is: If a crash occurs during a loading task, you can restart from the loading task that failed. If a crash occurs during an integration phase, restart from the first integration task, because integration into the target is within a transaction. This guideline applies only to one interface at a time. If several interfaces are chained and only the last one performs the commit, then they should all be restarted because the transaction runs over several interfaces.
To restart from a specific task or step:
In Operator Navigator, navigate to this task or step, edit it and switch it to Waiting state.
Set all tasks and steps after this one in the Operator tree view to Waiting state.
Restart the session using one of the following methods:
From a Web Service. See Section 20.11.4, "Restarting a Session Using a Web Service" for more information.
From ODI Console. See Section 22.2.3, "Managing Scenarios and Sessions".
WARNING:
When restarting a session, all connections and transactions to the source and target systems are re-created, and not recovered from the previous session run. As a consequence, uncommitted operations on transactions from the previous run are not applied, and data required for successfully continuing the session may not be present.
To restart a session from Oracle Data Integrator Studio:
In Operator Navigator, select the session that you want to restart.
Right-click and select Restart.
In the Choose Restart Mode dialog, select the agent you want to use for running the new session.
Click OK.
When Oracle Data Integrator has restarted the session, the Session Started dialog appears.
Before restarting a session from a command line, read carefully the following requirements:
The command line scripts, which are required for performing the tasks described in this section, are only available if you have installed the Oracle Data Integrator Standalone Agent. See the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator for information about how to install the Standalone Agent.
To use this command the connection to your repository must be configured in the odiparams file. See Chapter 4, "Managing Agents" for more information.
When restarting a session from a command line, the session is not started by default against a remote run-time agent, but is executed by a local Java process started from the command line. This process can be aborted locally, but cannot receive a session stop signal as it is not a real run-time agent. As a consequence, sessions started this way cannot be stopped remotely.
If you want to start the session against a run-time agent, you must use the AGENT_URL parameter.
To restart a session from a command line:
Change directory to the /agent/bin directory of the Oracle Data Integrator installation.
Enter the following command to start a scenario.
On UNIX systems:
./restartsession.sh <session_number> [-AGENT_URL=<remote_agent_url>]
On Windows systems:
restartsession.bat <session_number> ["-AGENT_URL=<remote_agent_url>"]
Table 20-3 lists the different parameters of this command, both mandatory and optional. The parameters are preceded by the "-" character and the possible values are preceded by the "=" character. You must follow the character protection syntax specific to the operating system on which you enter the command.
Table 20-3 restartsess command Parameters
| Parameters | Description |
|---|---|
|
|
Number (ID) of the session to be restarted. |
|
|
URL of the run-time agent that will restart this session. By default the session is executed by a local Java process started from the command line. |
Note:
To use this command the connection to your repository must be configured in the odiparams file. See Section 4.3, "Managing Agents" for more information.Note:
When restarting a session from a command line, the session is not started by default against a remote run-time agent, but is executed by a local Java process started from the command line.If you want to start the session against a run-time agent, you must use the AGENT_URL parameter.
Any running or waiting session can be stopped. You may want to stop a session when you realize that for example your interface contains errors or when the execution takes a long time.
Note that there are two ways to stop a session:
Normal: The session is stopped once the current task is finished.
Immediate: The current task is immediately interrupted and the session is stopped. This mode allows to stop long-running tasks, as for example long SQL statements before they complete.
Note:
The immediate stop works only with technologies and drivers that support task interruption. It is supported if thestatement.cancel method is implemented in the JDBC driver.Note:
Only sessions that are running within a Java EE or standalone Agent can be stopped. Sessions running in the Studio built-in Agent or started with thestartscen.sh or startscen.bat script without the AGENT_URL parameter, cannot be stopped. See Section 20.3, "Executing a Scenario" for more information.Session can be stopped in several ways:
From ODI Console. See Section 22.2.3, "Managing Scenarios and Sessions".
To stop a session from Oracle Data Integrator Studio:
In Operator Navigator, select the running or waiting session to stop from the tree.
Right-click then select Stop Normal or Stop Immediate.
In the Stop Session Dialog, click OK.
The session is stopped and changed to Error status.
Before stopping a session from a command line, read carefully the following requirements:
The command line scripts, which are required for performing the tasks described in this section, are only available if you have installed the Oracle Data Integrator Standalone Agent. See the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator for information about how to install the Standalone Agent.
To use this command the connection to your repository must be configured in the odiparams file. See Chapter 4, "Managing Agents" for more information.
To stop a session from a command line:
Change directory to the /agent/bin directory of the Oracle Data Integrator installation.
Enter the following command to start a scenario.
On UNIX systems:
./stopsession.sh <session_id> [-AGENT_URL=<remote_agent_url>] [-STOP_LEVEL=<normal (default) | immediate>]
On Windows systems:
stopsession.bat <session_id> ["-AGENT_URL=<remote_agent_url>"]["-STOP_LEVEL=<normal (default) | immediate>"]
Table 20-3 lists the different parameters of this command, both mandatory and optional. The parameters are preceded by the "-" character and the possible values are preceded by the "=" character. You must follow the character protection syntax specific to the operating system on which you enter the command.
Table 20-4 StopSession command Parameters
| Parameters | Description |
|---|---|
|
|
Number (ID) of the session to be restarted. |
|
|
URL of the run-time agent that stops this session. By default the session is executed by a local Java process started from the command line. |
|
|
The level used to stop a running session. If it is omitted, |
Note:
To use this command the connection to your repository must be configured in the odiparams file. See Section 4.3, "Managing Agents" for more information.Load Plans can be executed in several ways:
From a Web Service. See Section 20.11.5, "Executing a Load Plan Using a Web Service" for more information.
From ODI Console. See Section 22.2.4, "Managing Load Plans".
Note:
A Load Plan cannot be executed using the ODI Studio built-in agent called Local (No Agent).In ODI Studio, you can run a Load Plan in Designer Navigator or in Operator Navigator.
To run a Load Plan in Designer Navigator or Operator Navigator:
In the Load Plans and Scenarios accordion, select the Load Plan you want to execute.
Right-click and select Execute.
In the Start Load Plan dialog, select the execution parameters:
Select the Context into which the Load Plan will be executed.
Select the Logical Agent that will run the step.
In the Variables table, enter the Startup values for the variables used in this Load Plan.
Click OK.
The Load Plan Started Window appears.
Click OK.
A new execution of the Load Plan is started: a Load Plan instance is created and also the first Load Plan run. You can review the Load Plan execution in the Operator Navigator.
You can start a Load Plan from a command line.
Before executing a Load Plan from a command line, read carefully the following requirements:
The command line scripts, which are required for performing the tasks described in this section, are only available if you have installed the Oracle Data Integrator Standalone Agent. See the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator for information about how to install the Standalone Agent.
To use this command, the connection to your repository must be configured in the odiparams file. See Chapter 4, "Managing Agents" for more information.
A Load Plan Run is started against a run-time agent identified by the AGENT_URL parameter.
To start a Load Plan from a command line:
Change directory to /agent/bin directory of the Oracle Data Integrator installation.
Enter the following command to start a Load Plan.
On UNIX systems:
./startloadplan.sh <load_plan_name> <context_code> -AGENT_URL=<agent_url> [-KEYWORDS=<keywords>] [<variable>=<value>]*
On WINDOWS systems:
startloadplan.bat <load_plan_name> <context_code> "-AGENT_URL=<agent_url>" ["-KEYWORDS=<keywords>"] ["<variable>=<value>"]*
Note:
On Windows platforms, it is necessary to "delimit" the command arguments containing "=" signs or spaces, by using double quotes. The command call may differ from the Unix command call. For example:On UNIX systems:
./startloadplan.sh DWLoadPlan DEV -AGENT_URL=http://localhost:20910/oraclediagent
On WINDOWS systems:
startloadplan.bat DWLoadPlan DEV "-AGENT_URL=http://localhost:20910/oraclediagent"
Table 20-5 lists the different parameters, both mandatory and optional. The parameters are preceded by the "-" character and the possible values are preceded by the "=" character. You must follow the character protection syntax specific to the operating system on which you enter the command.
Table 20-5 Startloadplan Command Parameters
| Parameters | Description |
|---|---|
|
<load_plan_name> |
Name of the Load Plan to be started (mandatory) |
|
<context_code> |
Code of the context used for starting the Load Plan. Note that if this value is not provided, the Load Plan uses the context of the session that calls it (mandatory) |
|
"-AGENT_URL=<agent_url>" |
URL of the Physical Agent that starts the Load Plan (mandatory) |
|
["-KEYWORDS=<Keywords>"] |
Keywords to improve the organization of ODI logs by session folders and automatic classification. Enter a comma separated list of keywords that will be attached to this Load Plan. |
|
["variable>=<value> "]* |
Startup values for the Load Plan variables (optional). Note that project variables should be named For example:
|
Restarting a Load Plan, starts a new run for the selected Load Plan instance. Note that when a Load Plan restarts the Restart Type parameter for the steps in error defines how the Load Plan and child sessions will be restarted. See Section 14.2.4.3, "Defining the Restart Behavior" and Section 20.4, "Restarting a Session" for more information.
Note:
Restarting a Load Plan instance depends on the status of its most-recent (highest-numbered) run. Restart is only enabled for the most-recent run, if its status is Error.Load Plans can be restarted in several ways:
From a Web Service. See Section 20.11.7, "Restarting a Load Plan Instance Using a Web Service" for more information.
From ODI Console. See Section 22.2.4, "Managing Load Plans".
To restart a Load Plan from ODI Studio:
In Operator Navigator, select the Load Plan Run to restart from the Load Plan Executions accordion.
Right-click then select Restart.
In the Restart Load Plan Dialog, select the Agent that restarts the Load Plan.
Click OK.
The Load Plan is restarted and a new Load Plan run is created.
Before restarting a Load Plan from a command line, read carefully the following requirements:
The command line scripts, which are required for performing the tasks described in this section, are only available if you have installed the Oracle Data Integrator Standalone Agent. See the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator for information about how to install the Standalone Agent.
To use this command the connection to your repository must be configured in the odiparams file. See Chapter 4, "Managing Agents" for more information.
A Load Plan Run is restarted against a remote run-time agent identified by the AGENT_URL parameter.
To restart a Load Plan from a command line:
Change directory to /agent/bin directory of the Oracle Data Integrator installation.
Enter the following command to start a Load Plan.
On UNIX systems:
./restartloadplan.sh <load_plan_instance_id> -AGENT_URL=<agent_url>
On WINDOWS systems:
restartloadplan.bat <load_plan_instance_id> "-AGENT_URL=<agent_url>"
Note:
On Windows platforms, it is necessary to "delimit" the command arguments containing "=" signs or spaces, by using double quotes. The command call may differ from the Unix command call.Table 20-6 lists the different parameters, both mandatory and optional. The parameters are preceded by the "-" character and the possible values are preceded by the "=" character. You must follow the character protection syntax specific to the operating system on which you enter the command.
Any running or waiting Load Plan Run can be stopped. You may want to stop a Load Plan Run when you realize that for example your Load Plan contains errors or when the execution takes a long time.
Note that there are two ways to stop a Load Plan Run:
Stop Normal: In normal stop mode, the agent in charge of stopping the Load Plan sends a Stop Normal signal to each agent running a session for this Load Plan. Each agent will wait for the completion of the current task of the session and then end the session in error. Exception steps will not be executed by the Load Plan and once all exceptions are finished the load plan is moved to an error state.
Stop Immediate: In immediate stop mode, the agent in charge of stopping the Load Plan sends a Stop immediate signal to each agent running a session for this Load Plan. Each agent will immediately end the session in error and not wait for the completion of the current task of the session. Exception steps will not be executed by the Load Plan and once all exceptions are finished the load plan is moved to an error state.
Load Plans can be stopped in several ways:
From a Web Service. See Section 20.11.6, "Stopping a Load Plan Run Using a Web Service" for more information.
From ODI Console. See Section 22.2.4, "Managing Load Plans".
To stop a Load Plan Run from ODI Studio:
In Operator Navigator, select the running or waiting Load Plan Run to stop from the Load Plan Executions accordion.
Right-click then select Stop Normal or Stop Immediate.
In the Stop Load Plan Dialog, select the Agent that stops the Load Plan.
Click OK.
The Load Plan run is stopped and changed to Error status.
Before stopping a Load Plan from a command line, read carefully the following requirements:
The command line scripts, which are required for performing the tasks described in this section, are only available if you have installed the Oracle Data Integrator Standalone Agent. See the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator for information about how to install the Standalone Agent.
To use this command the connection to your repository must be configured in the odiparams file. See Chapter 4, "Managing Agents" for more information.
A Load Plan Run signal is sent by a remote run-time agent identified by the AGENT_URL parameter.
To stop a Load Plan run from a command line:
Change directory to /agent/bin directory of the Oracle Data Integrator installation.
Enter the following command to start a Load Plan.
On UNIX systems:
./stoploadplan.sh <load_plan_instance_id> [<load_plan_run_count>] -AGENT_URL=<agent_url> [-STOP_LEVEL=<normal (default) | immediate>]
On WINDOWS systems:
stoploadplan.bat <load_plan_instance_id> [<load_plan_run_count>] "-AGENT_URL=<agent_url>" ["-STOP_LEVEL=<normal (default) | immediate>"]
Table 20-7 lists the different parameters, both mandatory and optional. The parameters are preceded by the "-" character and the possible values are preceded by the "=" character. You must follow the character protection syntax specific to the operating system on which you enter the command.
Table 20-7 Stoploadplan Command Parameters
| Parameters | Description |
|---|---|
|
<load_plan_instance_id> |
ID of the running Load Plan run that is to be stopped (mandatory) |
|
[<load_plan_run_count>] |
Load Plan run count of the load plan instance. It prevents unintentional stopping of a load plan run that happens to be the latest one. If it is omitted, the last Load Plan run count will be used (optional) |
|
"-AGENT_URL=<agent_url>"] |
URL of the Physical Agent that starts the Load Plan (optional) |
|
[-STOP_LEVEL=<normal (default) | immediate>] |
Level used to stop the Load Plan run. Default is |
Note:
On Windows platforms, it is necessary to "delimit" the command arguments containing "=" signs or spaces, by using double quotes. The command call may differ from the Unix command call.You can schedule the executions of your scenarios and Load Plans using the Oracle Data Integrator built-in scheduler or an external scheduler. Both methods are detailed in this section:
Section 20.9.1, "Scheduling a Scenario or a Load Plan with the Built-in Scheduler"
Section 20.9.2, "Scheduling a Scenario or a Load Plan with an External Scheduler"
You can attach schedules to scenarios and also to Load Plans. Such schedules are managed by the scheduler built-in run-time agent.
It is important to understand that a schedule concerns only one scenario or one Load Plan, while a scenario or a Load Plan can have several schedules and can be scheduled in several ways. The different schedules appear under the Scheduling node of the scenario or Load Plan. Each schedule allows a start date and a repetition cycle to be specified.
For example:
Schedule 1: Every Thursday at 9 PM, once only.
Schedule 2: Every day from 8 am to 12 noon, repeated every 5 seconds.
Schedule 3: Every day from 2 PM to 6 PM, repeated every 5 seconds, with a maximum cycle duration of 5 hours.
To schedule a scenario or a Load Plan from Oracle Data Integrator Studio.
Right-click the Scheduling node under a scenario or a Load Plan in the Designer or Operator Navigator.
Select New Scheduling. The Scheduling editor is displayed.
On the Definition tab of the Scheduling editor specify the parameters as follows:
| Properties | Description |
|---|---|
| Context | Context into which the scenario or Load Plan is started. |
| Agent | Agent executing the scenario or Load Plan. |
| Log Level | Level of logging information to retain. |
The Status parameters define the activation of the schedule.
| Properties | Description |
|---|---|
| Active | The scheduling will be active when the agent is restarted or when the scheduling of the physical agent is updated. |
| Inactive | The schedule is not active and will not run. |
| Active for the period | Activity range of the schedule. A schedule active for a period of time will only run within this given period. |
The Execution parameters define the frequency of execution for each execution cycle.
| Properties | Description |
|---|---|
| Execution | Frequency of execution option (annual, monthly,... simple). This option is completed by a set of options that depend on this main option. |
On the Execution Cycle tab, specify the parameters for the repeat mode of the scenario as follows:
| Properties | Description |
|---|---|
| None (Execute once) | The scenario or Load Plan is executed only one time. |
| Many times | The scenario or Load Plan is repeated several times.
|
| Constraints | Allows limitations to be placed on one cycle iteration, in the event of a problem during execution.
|
On the Variables tab, unselect Latest Value for variables for which you want to provide a Value. Only variables used in the scenario or Load Plan and flagged as parameters for this scenario or Load Plan appear in this tab.
From the File menu, click Save.
The new schedule appears under the Scheduling node of the scenario or Load Plan.
The schedule changes are taken into account by the run-time agent when it starts or when it receives a schedule update request.
An agent reads schedules when starting on all the repositories attached to the master repository it connects to. It is possible, if a schedule was added for this agent in a given repository, to refresh the agent schedule.
To update an agent's schedule:
In Topology Navigator expand the Agents node in the Physical Architecture accordion.
Select the Physical Agent you want to update the schedule.
Right-click and select Update Scheduling...
In the Select Repositories dialog, select the repositories from which you want to read scheduling information. Check Select All Work Repositories to read scheduling information from all these repositories.
Click OK.
The agent refreshes and re-computes its in-memory schedule from the schedules defined in these repositories.
You can also use the OdiUpdateAgentSchedule tool to update an agent's schedule.
You can view the scheduled tasks of all your agents or you can view the scheduled tasks of one particular agent.
Note:
The Scheduling Information is retrieved from the Agent's in-memory schedule. The Agent must be started and its schedule refreshed in order to display accurate schedule information.Displaying the Schedule for All Agent
To display the schedule for all agents:
Select Connect Navigator >Scheduling... from the Operator Navigator toolbar menu.
The View Schedule dialog appears, displaying the schedule for all agents.
Displaying the Schedule for One Agent
To display the schedule for one agent:
In Topology Navigator expand the Agents node in the Physical Architecture accordion.
Select the Physical Agent you want to update the schedule.
Right-click and select View Schedule.
The Schedule Editor appears, displaying the schedule for this agent.
Note:
The Scheduling Information is retrieved from the Agent's schedule. The Agent must be started and its schedule refreshed in order to display accurate schedule information.Using the View Schedule Dialog
The schedule is displayed in form of a Gantt diagram. Table 20-8 lists the details of the Schedule dialog.
|
Selected Agent |
Agent for which the Schedule is displayed. You can display also the schedule of all agents by selecting All Agents. |
|---|---|
|
Selected Work Repository |
Only the scenarios executed in the selected Work Repository are displayed in the schedule. Default is All Work Repositories. |
|
Scheduling from... to... |
Time range for which the scheduling is displayed. Click Refresh to refresh this schedule. |
|
Update |
Click Update to update the schedule for the selected agent(s) |
|
Time Range |
The time range specified (1 hour, 2 hours, and so forth) allows you to center the diagram on the current time plus this duration. This feature provides a vision of the sessions in progress plus the incoming sessions. You can use the arrows to move the range forward or backward. |
|
Scenarios details |
This panel displays the details and execution statistics for each scheduled scenario. |
If you select a zone in the diagram (keep the mouse button pressed), you automatically zoom on the select zone.
By right-clicking in the diagram, you open a context menu for zooming, saving the diagram as an image file, printing or editing the display properties.
To start a scenario or a Load Plan with an external scheduler, do one of the following:
Use the startscen or startloadplan command from the external scheduler
Use the web service interface for triggering the scenario or Load Plan execution
For more information, see:
If a scenario or a Load Plan completes successfully, the return code will be 0. If not, the return code will be different than 0. This code will be available in:
The return code of the command line call. The error message, if any, is available on the standard error output.
The SOAP response of the web service call. The web service response includes also the session error message, if any.
In Oracle Data Integrator you have the possibility at design-time to simulate an execution. Simulating an execution generates and displays the code corresponding to the execution without running this code. Execution simulation provides reports suitable for code review.
Note:
No session is created in the log when the execution is started in simulation mode.To simulate an execution:
In the Project view of the Designer Navigator, select the object you want to execute.
Right-click and select Execute.
In the Execution dialog, set the execution parameters and select Simulation. See Table 20-1 for more information.
Click OK.
The Simulation report is displayed.
You can click Save to save the report as.xml or.html file.
This section explains how to use a web service to perform run-time operations. it contains the following sections.
Section 20.11.3, "Monitoring a Session Status Using a Web Service"
Section 20.11.5, "Executing a Load Plan Using a Web Service"
Section 20.11.6, "Stopping a Load Plan Run Using a Web Service"
Section 20.11.7, "Restarting a Load Plan Instance Using a Web Service"
Section 20.11.8, "Monitoring a Load Plan Run Status Using a Web Service"
Section 20.11.11, "Accessing the Web Service from a Command Line"
Section 20.11.12, "Using the Run-Time Web Services with External Authentication"
Section 20.11.14, "Using Asynchronous Web Services with Callback"
Oracle Data Integrator includes web services for performing run-time operations. These web services are located in two places:
In the run-time agent, a web service allows starting a scenario or a Load Plan, monitoring a session status or a Load Plan run status, and restarting a session or a Load Plan instance, as well as stopping a Load Plan run. To use operations from this web service, you must first install and configure a standalone or a Java EE agent.
A dedicated public web service component provides operations to list the contexts and scenarios available. To use operations from this web service, you must first install and configure this component in a Java EE container.
The following applies to the SOAP request used against the agent and public web services
The web services operations accept password in a plain text in the SOAP request. Consequently, it is strongly recommended to use secured protocols (HTTPS) to invoke web services over a non-secured network. You can alternately use external authentication. See Section 20.11.12, "Using the Run-Time Web Services with External Authentication" for more information.
Repository connection information is not necessary in the SOAP request as the agent or public web service component is configured to connect to a master repository. Only an ODI user and the name of a work repository are required to run most of the operations.
The invokeStartScen operation of the agent web service starts a scenario in synchronous or asynchronous mode; in a given work repository. The session is executed by the agent providing the web service.
<OdiStartScenRequest>
<Credentials>
<OdiUser>odi_user</OdiUser>
<OdiPassword>odi_password</OdiPassword>
<WorkRepository>work_repository</WorkRepository>
</Credentials>
<Request>
<ScenarioName>scenario_name</ScenarioName>
<ScenarioVersion>scenario_version</ScenarioVersion>
<Context>context</Context>
<LogLevel>log_level</LogLevel>
<Synchronous>synchronous</Synchronous>
<SessionName>session_name</SessionName>
<Keywords>session_name</Keywords>
<Variables>
<Name>variable_name</name>
<Value>variable_value</Value>
</Variables>
</Request>
</OdiStartScenRequest>
The scenario execution returns the session ID in a response that depends on the value of the synchronous element in the request.
In synchronous mode (Synchronous=1), the response is returned once the session has completed, and reflects the execution result.
In asynchronous mode (Synchronous=0), the response is returned once the session is started, and only indicates the fact whether the session was correctly started or not.
This operation returns a response in the following format:
<?xml version = '1.0' encoding = 'ISO-8859-1'?><ns2:OdiStartScenResponse xmlns:ns2="xmlns.oracle.com/odi/OdiInvoke/"> <Session>543001</Session></ns2:OdiStartScenResponse>
The getSessionStatus operation of the agent web service returns the status of one or more sessions in a given repository, identified by their Session Numbers provided in the SessionIds element. It manages both running and completed sessions.
<OdiGetSessionsStatusRequest>
<Credentials>
<OdiUser>odi_user</OdiUser>
<OdiPassword>odi_password</OdiPassword>
<WorkRepository>work_repository</WorkRepository
</Credentials>
<SessionIds>session_number</SessionIds>
</OdiGetSessionsStatusRequest>
This operation returns a response in the following format:
<SessionStatusResponse>
<SessionId>session_id</SessionId>
<SessionStatus>status_code</SessionStatus>
<SessionReturnCode>return_code</SessionReturnCode>
</SessionStatusResponse>
The Return Code value is zero for successful sessions and possible status codes are:
D: Done
E: Error
M: Warning
Q: Queued
R: Running
W: Waiting
The invokeRestartSess operation of the agent web service restarts a session identified by its session number (provided in the SessionID element) in a given work repository. The session is executed by the agent providing the web service.
Only sessions in status Error or Waiting can be restarted. The session will resume from the last non-completed task (typically, the one in error).
Note that you can change the value of the variables or use the KeepVariables boolean element to reuse variables values from the previous session run.
<invokeRestartSessRequest>
<Credentials>
<OdiUser>odi_user</OdiUser>
<OdiPassword>odi_password</OdiPassword>
<WorkRepository>work_repository</WorkRepository>
</Credentials>
<Request>
<SessionID>session_number</SessionID>
<Synchronous>synchronous</Synchronous>
<KeepVariables>0|1</KeepVariables>
<Variables>
<Name>variable_name</name>
<Value>variable_value</Value>
</Variables>
</Request>
</invokeRestartSessRequest>
This operation returns a response similar to InvokeStartScen, depending on the Synchronous element's value.
The invokeStartLoadPlan operation of the agent web service starts a Load Plan in a given work repository. The Load Plan is executed by the agent providing the web service. Note the following concerning the parameters of the invokeStartLoadPlan operation:
OdiPassword: Use a password in clear text.
Context: Use the context code.
Keywords: If you use several keywords, enter a comma separated list of keywords.
Name: Use the fully qualified name for variables: GLOBAL.variable_name or PROJECT_CODE.variable_name
The following shows the format of the OdiStartLoadPlanRequest.
<OdiStartLoadPlanRequest>
<Credentials>
<OdiUser>odi_user</OdiUser>
<OdiPassword>odi_password</OdiPassword>
<WorkRepository>work_repository</WorkRepository>
</Credentials>
<StartLoadPlanRequest>
<LoadPlanName>load_plan_name</LoadPlanName>
<Context>context</Context>
<Keywords>keywords</Keywords>
<LoadPlanStartupParameters>
<Name>variable_name</Name>
<Value>variable_value</Value>
</LoadPlanStartupParameters>
</StartLoadPlanRequest>
</OdiStartLoadPlanRequest>
The invokeStartLoadPlan operation returns the following values in the response:
Load Plan Run ID
Load Plan Run Count
Master Repository ID
Master Repository timestamp
The following is an example of an OdiStartLoadPlan response:
<?xml version = '1.0' encoding = 'UTF8'?>
<ns2:OdiStartLoadPlanResponse xmlns:ns2="xmlns.oracle.com/odi/OdiInvoke/">
<executionInfo>
<StartedRunInformation>
<OdiLoadPlanInstanceId>2001</OdiLoadPlanInstanceId>
<RunCount>1</RunCount>
<MasterRepositoryId>0</MasterRepositoryId>
<MasterRepositoryTimestamp>1290196542926</MasterRepositoryTimestamp>
</StartedRunInformation>
</executionInfo>
</ns2:OdiStartLoadPlanResponse>
The invokeStopLoadPlan operation of the agent web service stops a running Load Plan run identified by the Instance ID and Run Number in a given work repository. The Load Plan instance is stopped by the agent providing the web service. Note that the StopLevel parameter can take the following values:
NORMAL: Waits until the current task finishes and then stops the session.
IMMEDIATE: Stops the session immediately, cancels all open statements and then rolls back the transactions.
See Section 20.8, "Stopping a Load Plan Run" for more information on how to stop a Load Plan run and Section 20.11.5, "Executing a Load Plan Using a Web Service" for more information on the other parameters used by the invokeStopLoadPlan operation.
<OdiStopLoadPlanRequest>
<Credentials>
<OdiUser>odi_user</OdiUser>
<OdiPassword>odi_password</OdiPassword>
<WorkRepository>work_repository</WorkRepository>
</Credentials>
<OdiStopLoadPlanRequest>
<LoadPlanInstanceId>load_plan_instance_id</LoadPlanInstanceId>
<LoadPlanInstanceRunCount>load_plan_run_count</LoadPlanInstanceRunCount>
<StopLevel>stop_level</StopLevel>
</OdiStopLoadPlanRequest>
</OdiStopLoadPlanRequest>
The invokeStopLoadPlan operation returns the following values in the response:
Load Plan Run ID
Load Plan Run Count
Master Repository ID
Master Repository timestamp
The following is an example of an OdiStopLoadPlan response:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:OdiStopLoadPlanResponse xmlns:ns2="xmlns.oracle.com/odi/OdiInvoke/">
<executionInfo>
<StoppedRunInformation>
<OdiLoadPlanInstanceId>3001</OdiLoadPlanInstanceId>
<RunCount>1</RunCount>
<MasterRepositoryId>0</MasterRepositoryId>
<MasterRepositoryTimestamp>1290196542926</MasterRepositoryTimestamp>
</StoppedRunInformation>
</executionInfo>
</ns2:OdiStopLoadPlanResponse>
</S:Body>
</S:Envelope>
The invokeRestartLoadPlan operation of the agent web service restarts a Load Plan instance identified by the Instance ID in a given work repository. The Load Plan instance is restarted by the agent providing the web service.
<OdiRestartLoadPlanRequest>
<Credentials>
<OdiUser>odi_user</OdiUser>
<OdiPassword>odi_password</OdiPassword>
<WorkRepository>work_repository</WorkRepository>
</Credentials>
<RestartLoadPlanRequest>
<LoadPlanInstanceId>load_plan_instance_id</LoadPlanInstanceId>
</RestartLoadPlanRequest>
</OdiRestartLoadPlanRequest>
The getLoadPlanStatus operation of the agent web service returns the status of one or more Load Plans by their Instance ID and Run Number in a given repository. It manages both running and completed Load Plan instances.
<OdiGetLoadPlanStatusRequest>
<Credentials>
<OdiUser>odi_user</OdiUser>
<OdiPassword>odi_password</OdiPassword>
<WorkRepository>work_repository</WorkRepository>
</Credentials>
<LoadPlans>
<LoadPlanInstanceId>load_plan_instance_id</LoadPlanInstanceId>
<LoadPlanRunNumber>load_plan_run_number</LoadPlanRunNumber>
</LoadPlans>
</OdiGetLoadPlanStatusRequest>
The getStopLoadPlanStatus operation returns the following values in the response:
Load Plan Run ID
Load Plan Run Count
Load Plan Run return code
Load Plan message
The following is an example of an OdiGetLoadPlanStatus response:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:OdiGetLoadPlanStatusResponse xmlns:ns2="xmlns.oracle.com/odi/OdiInvoke/">
<LoadPlanStatusResponse>
<LoadPlanInstanceId>3001</LoadPlanInstanceId>
<LoadPlanRunNumber>1</LoadPlanRunNumber>
<LoadPlanStatus>E</LoadPlanStatus>
<LoadPlanReturnCode>ODI-1530</LoadPlanReturnCode>
<LoadPlanMessage>ODI-1530: Load plan instance was stopped by user request.</LoadPlanMessage>
</LoadPlanStatusResponse>
</ns2:OdiGetLoadPlanStatusResponse>
</S:Body>
</S:Envelope>
The listContext operation of the public web service lists of all the contexts present in a master repository.
<listContextRequest>
<OdiUser>odi_user</OdiUser>
<OdiPassword>odi_password</OdiPassword>
<listContextRequest>
The listScenario operation of the public web service lists of all the scenarios present in a given work repository.
<listScenarioRequest>
<OdiUser>odi_user</OdiUser>
<OdiPassword>odi_password</OdiPassword>
<WorkRepository>work_repository</WorkRepository>
<listScenarioRequest>
Oracle Data Integrator contains two shell scripts for UNIX platforms that use the web service interface for starting and monitoring scenarios from a command line via the run-time agent web service operations:
startscenremote.sh starts a scenario on a remote agent on its web service. This scenario can be started synchronously or asynchronously. When started asynchronously, it is possible to have the script polling regularly for the session status until the session completes or a timeout is reached.
getsessionstatusremote.sh gets the status of a session via the web service interface. This second script is used in the startscenremote.sh script.
Before accessing a web service from a command line, read carefully the following important notes:
The command line scripts, which are required for performing the tasks described in this section, are only available if you have installed the Oracle Data Integrator Standalone Agent. See the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator for information about how to install the Standalone Agent.
Unlike the startscen.sh command line, these scripts rely on the lightweight WGET utility installed with the UNIX or Linux platform to perform the web service calls. It does not use any java code and uses a polling mechanism to reduce the number of running processes on the machine. These scripts are suitable when a large number of scenarios and sessions need to be managed simultaneously from a command line.
To start a scenario from a command line via the web service:
Change directory to the /agent/bin directory of the Oracle Data Integrator installation.
Enter the following command to start a scenario.
On UNIX systems:
./startscenremote.sh <scenario_name> <scenario_version> <context_code> <work_repository> <remote_agent_url> <odi_user> <odi_password> -l <log_level> -s <sync_mode> -n <session_name> -k <session_keyword> -a <assign_variable> -t <timeout> -i <interval> -h <http_timeout> -v
Table 20-9 lists the different parameters of this command, both mandatory and optional.
Table 20-9 Startscenremote command Parameters
| Parameters | Description |
|---|---|
|
|
Name of the scenario (mandatory). |
|
|
Version of the scenario (mandatory). If the version specified is -1, the latest version of the scenario is executed. |
|
|
Code of the execution context (mandatory). |
|
-l |
Level of logging information to retain. This parameter is in the format Example: |
|
|
Name of the work repository containing the scenario. |
|
|
URL of the run-time agent that will run this session. |
|
|
Name of the user used to run this sessions. |
|
|
This user's password. |
|
|
Execution mode:
|
|
|
Name of the session |
|
|
List of keywords attached to this session. These keywords make session identification easier. The list is a comma-separated list of keywords. |
|
|
Assign variable. Allows to assign a This parameter can be repeated to assign several variables. Do not use a hash sign ( For Example: |
|
|
Timeout in seconds for waiting for session to complete if sync_mode = 2. |
|
|
Polling interval for session status if sync_mode = 2. |
|
|
HTTP timeout for the web services calls. |
|
|
Verbose mode. |
To monitor the status of a session from a command line via the web service:
Change directory to the /agent/bin directory of the Oracle Data Integrator installation.
Enter the following command to start a scenario.
On UNIX systems:
./getsessionstatusremote.sh <session_number> <work_repository> <remote_agent_url> <odi_user> <odi_password> -w <wait_mode> -t <timeout> -i <interval> -h <http_timeout> -v
Table 20-10 lists the different parameters of this command, both mandatory and optional.
Table 20-10 GetSessionStatusRemote command Parameters
| Parameters | Description |
|---|---|
|
|
Number of the session to monitor. |
|
|
Name of the work repository containing the scenario. |
|
|
URL of the run-time agent that will run this session. |
|
|
Name of the user used to run this sessions. |
|
|
This user's password. |
|
|
Wait mode:
|
|
|
Timeout in seconds for waiting for session to complete if sync_mode = 2. |
|
|
Polling interval for session status if sync_mode = 2. |
|
|
HTTP timeout for the web services calls. |
|
|
Verbose mode. |
The web services examples in this chapter use an ODI authentication within the SOAP body, using the OdiUser and OdiPassword elements.
When external authentication is set up for the repository and container based authentication with Oracle Platform Security Services (OPSS) is configured (See Section 23.3.2, "Setting Up External Authentication" for more information), the authentication can be passed to the web service using HTTP basic authentication, WS-Security headers, SAML tokens and so forth. OPSS will transparently handle the authentication on the server-side with the identity provider. In such situation, the OdiUser and OdiPassword elements can be omitted.
The run-time web services will first try to authenticate using OPSS. If no authentication parameters have been provided, OPSS uses anonymous user and the OdiUser and OdiPassword are checked. Otherwise (this is in case of invalid credentials to OPSS) OPSS throws an authentication exception and the web service is not invoked.
Note:
OPSS authentication is only possible for a Public Web Service or JEE Agent deployed in a Oracle WebLogic Server.The web services described in this chapter optionally support WS-Addressing. WS-Addressing allows replying on an endpoint when a run-time web service call completes. For this purpose, two endpoints, ReplyTo and FaultTo, can be optionally specified in the SOAP request header.
These endpoints are used in the following way:
When the run-time web service call completes successfully, the result of an Action is sent to the ReplyTo endpoint.
If an error is encountered with the SOAP request or if Oracle Data Integrator is unable to execute the request, a message is sent to the FaultTo address. If the FaultTo address has not been specified, the error is sent to the ReplyTo address instead.
If Oracle Data Integrator encounters errors while processing the request and needs to raise an ODI error message, this error message is sent back to the ReplyTo address.
Note that callback operations do not operate in callback mode unless a valid ReplyTo address is specified.
The following is an example of a request that is sent to retrieve the session status for session 20001:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:odi="xmlns.oracle.com/odi/OdiInvoke/">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Action soapenv:mustUnderstand="1">xmlns.oracle.com/odi/OdiInvoke/getSessionStatus</wsa:Action>
<wsa:ReplyTo soapenv:mustUnderstand="1">
<wsa:Address>http://host001:8080/examples/servlets/servlet/RequestPrinter</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID soapenv:mustUnderstand="1">uuid:71bd2037-fbef-4e1c-a991-4afcd8cb2b8e</wsa:MessageID>
</soapenv:Header>
<soapenv:Body>
<odi:OdiGetSessionsStatusRequest>
<Credentials>
<!--You may enter the following 3 items in any order-->
<OdiUser></OdiUser>
<OdiPassword></OdiPassword>
<WorkRepository>WORKREP1</WorkRepository>
</Credentials>
<!--Zero or more repetitions:-->
<SessionIds>20001</SessionIds>
</odi:OdiGetSessionsStatusRequest>
</soapenv:Body>
</soapenv:Envelope>
The following call will be made to the ReplyTo address (http://host001:8080/examples/servlets/servlet/RequestPrinter).
Note that this call contains the response to the Action specified in the request, and includes the original MessageID to correlate request and response.
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<To xmlns="http://www.w3.org/2005/08/addressing">http:// host001:8080/examples/servlets/servlet/RequestPrinter</To>
<Action xmlns="http://www.w3.org/2005/08/addressing">xmlns.oracle.com/odi/OdiInvoke/:requestPortType:getSessionStatusResponse</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:eda383f4-3cb5-4dc2-988c-a4f7051763ea</MessageID>
<RelatesTo xmlns="http://www.w3.org/2005/08/addressing">uuid:71bd2037-fbef-4e1c-a991-4afcd8cb2b8e</RelatesTo>
</S:Header>
<S:Body>
<ns2:OdiGetSessionsStatusResponse xmlns:ns2="xmlns.oracle.com/odi/OdiInvoke/">
<SessionStatusResponse>
<SessionId>26001</SessionId>
<SessionStatus>D</SessionStatus>
<SessionReturnCode>0</SessionReturnCode>
</SessionStatusResponse>
</ns2:OdiGetSessionsStatusResponse>
</S:Body>
</S:Envelope>
For more information on WS-Adressing, visit these World Wide Web Consortium (W3C) web sites at the following URLs:
Web Services Addressing: http://www.w3.org/Submission/ws-addressing/
WS-Addressing SOAP Binding : http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/
WS-Addressing WSDL Binding : http://www.w3.org/TR/2006/WD-ws-addr-wsdl-20060216/
Long-running web service operations can be started asynchronously following the pattern of JRF asynchronous web services or asynchronous BPEL processes. These follow a "request-response port pair" pattern.
In this pattern, the web service client implements a callback operation. When the server completes the operation requested by the client, it sends the result to this callback operation.
Two specific operations in the agent web service support this pattern: invokeStartScenWithCallback and invokeRestartSessWithCallback.
These operations provide the following features:
They do not return any response. These are one way operations.
The client invoking these two operation must implement respectively the invokeStartSceCallback and invokeRestartSessCallback one way operations. Results from the invokeStartScenWithCallback and invokeRestartSessWithCallback actions are sent to these operations.
The invocation should provide in the SOAP header the ReplyTo and possibly FaultTo addresses. If the methods are invoked without a ReplyTo address, the operation will execute synchronously (which corresponds to a invokeStartScen or invokeRestartSess operation). When a fault is generated in the operation, it will be sent to the ReplyTo address or FaultTo address.
A scenario or session started synchronously using the invokeStartScenWithCallback and invokeRestartSessWithCallback will start and will not return any SOAP response, as they are one way operations. When the session completes, the response is sent the callback address.
Note:
Oracle BPEL takes care of automatically implementing these operations and sends out WS-Addressing headers that point to these endpoints.