| Oracle® Fusion Middleware Web Service Developer's Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E14109-02 |
|
|
View PDF |
| Oracle® Fusion Middleware Web Service Developer's Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E14109-02 |
|
|
View PDF |
If you are developing services for Oracle WebCenter Interaction, you will need to understand the system and prepare your IDE for use with the Oracle WebCenter Interaction Development Kit (IDK). This chapter contains instructions for setting up an Oracle WebCenter Interaction Development Kit (IDK) development environment, and important background information on the Oracle WebCenter Interaction development environment.
Oracle WebCenter Interaction Development Kit (IDK) Projects: This section provides step-by-step instructions for the most common tasks in setting up a development environment.
Oracle WebCenter Interaction Logging Utilities: Oracle WebCenter Interaction Logging Utilities are a collection of debugging and logging solutions available for use in Oracle WebCenter Interaction.
Server Communication and the Gateway: This section explains how Oracle WebCenter Interaction acts as a gateway, brokering transactions between client computers and external resources. This section also provides detailed information on HTTP and CSP, the protocols that define the syntax of communication between Oracle WebCenter Interaction and external resources.
The following sections provide step-by-step instructions for the most common tasks in setting up a development environment. For details on installing or downloading the Oracle WebCenter Interaction Development Kit (IDK), see the installation guide on Oracle Technology Network at http://www.oracle.com/technology/index.html.
Java
Java: Setting Up a Custom Oracle WebCenter Interaction Development Kit (IDK) Project in Eclipse
Java: Deploying a Custom Oracle WebCenter Interaction Development Kit (IDK) Project in Eclipse
Java: Debugging a Custom Oracle WebCenter Interaction Development Kit (IDK) Project
.NET
This section describes how to set up a custom Java Oracle WebCenter Interaction Development Kit (IDK) project in Eclipse. The process is different depending on whether or not Eclipse Web Tools Platform (WTP) is installed:
Note:
These instructions assume you have installed the Java version of the Oracle WebCenter Interaction Development Kit (IDK).
These instructions describe how to set up a custom Java Oracle WebCenter Interaction Development Kit (IDK) project in Eclipse stand-alone, without Web Tools Platform (WTP) installed.
Open Eclipse and click File > New > Project.
Type the Project Name (for example, "idkproject"). Click Next and Finish.
In the Package Explorer in Eclipse, right-click on the new project and click Properties > Java Build Path > Libraries > Add External Jars.
Select the *.jar files from the IDK installation directory under the idk\<version>\devkit\java\WEB-INF\lib directory. Click OK.
These steps describe how to set up a custom Java Oracle WebCenter Interaction Development Kit (IDK) project in Eclipse with Web Tools Platform (WTP) installed.
Open Eclipse and click File > New > Other > Web > Dynamic Web Project.
Type the Project Name (for example, "idkproject").
Choose a Target Runtime from the drop-down list. If you have not previously configured a server runtime, click New to configure your Apache Tomcat setup.
Click Finish to complete the Dynamic Web Project wizard.
Import the IDK Web project template:
Right-click the project in the Project Explorer and click Import > General > File System.
To define the From directory field, navigate to the IDK root directory and select the \devkit\WEB-INF folder.
Change the Into folder field to <project name>/WebContent/WEB-INF.
Click Finish.
Note:
The Eclipse Web project view hides the imported JARs stored in WEB-INF/lib and puts those files under ./Java Resources/src/Libraries/Web App Libraries.
These steps describe how to deploy a custom Java Oracle WebCenter Interaction Development Kit (IDK) project in Eclipse. The process is different depending on whether or not Web Tools Platform (WTP) is installed:
Note:
The instructions below are for Apache Tomcat or Oracle WebLogic. For IBM WebSphere, you must create a .war or .ear file that is compatible with IBM WebSphere. You must first create an appropriate server-config.wsdd using the Oracle WebCenter Interaction Development Kit (IDK) DeployServlet or the supplied service wsdd files. See the IBM WebSphere documentation for detailed instructions.
These steps describe how to deploy a custom Java IDK project in Eclipse stand-alone (without Web Tools Platform (WTP) installed).
Deploy the Oracle WebCenter Interaction Development Kit (IDK) in your application server:
Create a folder for the custom project in the application server's \webapps directory. (For example, if Apache Tomcat is installed in C:\tomcat and the project name is "idkproject", the path would be C:\tomcat\webapps\idkproject.)
Navigate to the IDK installation directory and copy the WEB-INF and its \LIB subfolder to the directory you created in the previous step. This loads Apache AXIS into the application server.
Confirm that Apache AXIS is available by opening the following page in a browser: http://<hostname:port>/<projectname>/servlet/AxisServlet. (Change <hostname:port> to fit your application server, for example, localhost:8080 for Apache Tomcat. Change <projectname> to the name of the folder you created in step 1a.) The browser should display the message "And now... Some Services" and a list of installed services.
Compile the class that implements the IDK interface(s) and copy the entire package structure to the appropriate location in your web application, usually the \WEB-INF\classes directory.
Content services, identity services and SCI pages require additional configuration. You must add the custom class to the appropriate *Impl keys in the web.xml file in the WEB-INF directory. For details, see XXX_missing x-ref to ref_idk_deploymentimplkeys.dita_XXX.
Start your application server. In most cases, you must restart your application server after copying a file.
These steps describe how to deploy a custom Java Oracle WebCenter Interaction Development Kit (IDK) project in Eclipse with Web Tools Platform (WTP) installed.
These instructions use Apache Tomcat as an example.
Define the server in Eclipse:
Click File > New > Other > Server > Server and click Next.
Select the server type (Apache Tomcat v5.0) and click Next.
Select the Apache Tomcat v5.0 installation directory and click Next.
Add your custom project to the list of configured projects and click Finish.
Run and debug the application:
In Project Explorer, right-click your custom project and click Debug As > Debug On Server.
Select the existing server and click Finish.
Content services, identity services and custom preference (SCI) pages require additional configuration. You must add the custom class to the appropriate *Impl keys in the web.xml file in the WEB-INF directory. For details, see XXX_missing x-ref to ref_idk_deploymentimplkeys.dita_XXX.
When Apache Tomcat starts in a new Servers tab, hit http://localhost:8080/<projectname>/servlet/AxisServlet to ensure that Axis has deployed correctly and the web service APIs are correctly configured.
After you create a custom Oracle WebCenter Interaction Development Kit (IDK) project, you must deploy it in your Java application server.
These instructions use Apache Tomcat as an example.
Define the server in Eclipse:
Click File > New > Other > Server > Serverand click Next.
Select the server type as Apache Tomcat v5.0 and click Next.
Select the Apache Tomcat v5.0 installation directory and click Next.
Add your project to the list of configured Apache Tomcat projects and click Finish.
Content services, identity services and SCI pages require additional configuration. You must add the custom class to the appropriate *Impl keys in the web.xml file in the WEB-INF directory. For details on Impl keys, see XXX_missing x-ref to ref_idk_deploymentimplkeys.dita_XXX.
Run and debug the application:
In Eclipse Project Explorer, right-click your project and click Debug As > Debug On Server.
Select the existing server and click Finish.
When Apache Tomcat starts in a new Servers tab, hit http://localhost:8080/<project name>/servlet/AxisServlet to ensure that Axis has deployed correctly and the web service APIs are correctly configured.
These steps describe how to set up a custom .NET Oracle WebCenter Interaction Development Kit (IDK) project in Visual Studio.
Note:
These instructions assume you have installed the .NET version of the Oracle WebCenter Interaction Development Kit (IDK).
Start Visual Studio and click File > New Project > C# Projects > ASP.NET Web Service.
Type an intuitive name in the Location field.
Delete Service1.asmx and Web.config.
In the new project, click File > Add Existing Item.
Browse to the \devkit folder in the IDK installation directory.
In the File Types mask, click All Files.
Select all the .asmx files and Web.config. Do not select the \bin directory.
Click Open. You will be prompted to create a class file for each .asmx file; click No for each file.
In the Solution Explorer (usually in the upper right), you should see the project you created in step 1. Add the IDK assemblies:
Right-click References and click Add Reference.
Browse to the \devkit\bin folder in the IDK installation directory.
Select the assemblies to add to the bin directory: all the .dll files (Ctrl+A). These are the assemblies that resolve the references in the *.asmx files.
If you are using the standard (un-signed) version of the IDK, select all the .dll files (Ctrl+A).
If you are using the signed dll version of the IDK, select only Plumtree.openlog-framework_signed.dll. (You must deploy the other assemblies in the GAC as described in step f below.)
Click Open > OK.
In the Solution Explorer References, confirm that you now see idk, openfoundation, etc.
If you are using the signed dll version of the IDK, deploy the following assemblies in the GAC:
Plumtree.EDK_signed.dll
OpenFoundation_signed.dll
Plumtree.openkernel_signed.dll
Plumtree.openlog-framework_signed.dll
Plumtree.pmb_signed.dll
Plumtree.RAT_signed.dll
Click File > Add New Item to create new classes and complete your project.
These steps describe how to deploy a custom .NET Oracle WebCenter Interaction Development Kit (IDK) project in IIS.
These instructions assume you have set up Visual Studio for IDK development as described in the previous section.
Compile the class that implements the Oracle WebCenter Interaction Development Kit (IDK) interface(s).
Content services, identity services and SCI pages require additional configuration. You must add the class and the assembly that contains it to the appropriate *Assembly and *Impl keys in the web.config file in your project. For details, see XXX_missing x-ref to ref_idk_deploymentimplkeys.dita_XXX.
If you do not already have a virtual directory in IIS for your services, add one using the steps below:
Navigate to Internet Services Manager (Internet Information Services) in the Control Panel under Administrative Tools.
Select Default Web Site.
Click Action > New > Virtual Directory and type the name of your Visual Studio location.
Click Next twice. Type the path to the home directory for the IDK: <installdir>\idk\6.0\devkit\dotnet.
Check both the Read and Scripts only checkboxes if they are cleared (they should be checked by default). Click Next then click Finish.
Copy the compiled class files to the \bin folder in the <installdir>\idk\<version>\devkit\dotnet directory.
Oracle WebCenter Interaction Logging Utilities are a collection of debugging and logging solutions available for use in Oracle WebCenter Interaction.
Oracle WebCenter Interaction Logging Utilities allow for a wide variety of logging solutions. The Oracle WebCenter Interaction Development Kit (IDK) provides a remote API that allows you to send logging messages from remote web applications.
This chapter contains the following sections:
Configuring Oracle WebCenter Interaction Development Kit (IDK) Logging: Oracle WebCenter Interaction Development Kit (IDK) logging is not enabled by default. You can enable logging options programmatically or using the web.xml or Web.config file distributed with the IDK.
Using the Oracle WebCenter Interaction Development Kit (IDK) Logging API: The Oracle WebCenter Interaction Development Kit (IDK) logging API allows you to send log messages from remote services and applications to a variety of logging receivers. This section explains how to use the logging API from Java and .NET applications and from the command line.
To enable and configure Oracle WebCenter Interaction Development Kit (IDK) logging, first determine how the IDK is deployed.
Oracle WebCenter Interaction Development Kit (IDK) logging is disabled by default. If logging is enabled, it is sent only to the local machine by default, requiring direct access to the machine to view the logs. These default settings were chosen to secure potentially sensitive information present in log messages.
If the Oracle WebCenter Interaction Development Kit (IDK) is deployed as a Web application to support Integration Service implementations, edit the distributed Web application configuration file (web.xml or Web.config). For details, see Configuring Java Oracle WebCenter Interaction Development Kit (IDK) Logging (web.xml) or Configuring .NET Oracle WebCenter Interaction Development Kit (IDK) Logging (Web.config)
If the Oracle WebCenter Interaction Development Kit (IDK) is deployed as a library supporting a Web application (for example, a portlet), copy and paste the configuration parameters from the IDK's distributed web.xml/Web.config into your Web application configuration file. For details, see Configuring Java Oracle WebCenter Interaction Development Kit (IDK) Logging (web.xml) or Configuring .NET Oracle WebCenter Interaction Development Kit (IDK) Logging (Web.config).
If the Oracle WebCenter Interaction Development Kit (IDK) is deployed as a stand-alone application outside a Web application context, such as report-generating or data loading and dumping applications using the PRC, use programmatic configuration to initialize logging parameters. Programmatic logging configuration can be done at startup, or by using a static initialization call on a façade class that the Web application runtime code uses to obtain logging components or logger instances. For details, see Using the Oracle WebCenter Interaction Development Kit (IDK) Logging API.
To use the Oracle WebCenter Interaction Development Kit (IDK) Logging API, you must configure the logging receiver to read logs from the IDK. To configure the log receiver, you must know the logging application name. The Oracle WebCenter Interaction Development Kit (IDK) logging application name is configured in the Web application configuration file or set via the initialize() method in the Logging API.
Note:
Verbose logging cannot be enabled programmatically; you must change a setting in the web.xml or Web.config file.
For web services using the Java Oracle WebCenter Interaction Development Kit (IDK), the web.xml file is the standard way to configure log instrumentation.
The example below shows the logging settings only. The bulk of the web.xml file has been omitted; environment keys are inserted at the end according to the DTD.
<?xml version='1.0' encoding='ISO-8859-1'?>
<!DOCTYPE web-app
PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
'http://java.sun.com/j2ee/dtds/web-app_2.2.dtd'>
<web-app>
...
<env-entry>
<env-entry-name>ptedk.VerboseLogging</env-entry-name
<env-entry-value>true</env-entry-value>
<env-entry-type>java.lang.Boolean</env-entry-type>
</env-entry>
<env-entry>
<env-entry-name>ptedk.LoggingApplicationName</env-entry-name>
<env-entry-value>EDK</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>
<env-entry>
<env-entry-name>ptedk.LogToNetwork</env-entry-name>
<env-entry-value>true</env-entry-value>
<env-entry-type>java.lang.Boolean</env-entry-type>
</env-entry>
<web-app>
If you are running the .NET Oracle WebCenter Interaction Development Kit (IDK) as a web application that hosts Web services (that do not use the logging API), the Web.config file is the best way to configure log instrumentation.
The Oracle WebCenter Interaction Development Kit (IDK) Web.config follows the normal precedence rules of IIS Web.config: within a web application, machine.config is read first for configuration values, then overlaid with Web.config from each parent directory within the web application subtree down to the directory containing the running code. The example below shows the logging settings only. All .NET Web applications have Web.config files. If the configuration file does not have an <appSettings> section, it can be added along with the key-value pairs to configure logging.
<configuration>
<appSettings>
<add key="ptedk.LoggingApplicationName" value="Bulk-Document-Loader" />
<add key="ptedk.LogToNetwork" value="true" />
<add key="ptedk.VerboseLogging" value="true" />
</appSettings>
<system.web>
...
</system.web>
</configuration>
For stand-alone .NET applications outside a web application context, use programmatic configuration. For details, see Using Oracle WebCenter Interaction Development Kit (IDK) Logging in .NET.
This page summarizes logging levels and their implementation in Oracle WebCenter Interaction Development Kit (IDK) logging.
The Oracle WebCenter Interaction Development Kit (IDK) ILogger interface provides access to all eight standard logging levels.
Table 1-1 Severity-Based Logging Levels
| Logging Level | Description | IDK Implementation |
|---|---|---|
|
Debug |
The most common and numerous log call, used for detailed call tracing and parameter logging. The message should contain a detailed descriptive message reporting a minor step taken in the code or providing variable values (or both). |
Remote call tracing. Function parameters. ToString() of portlet settings or service request. |
|
Info |
Used for normal but significant events. Reports a common operation that is of possible interest, for example, serving a new user request or making a remote procedure call. |
New portlet or service request. PRC session initialization (login). The IDK logging service sends an Info message to the "EDK main" logging component when it is initialized. |
|
Warn |
Used for minor problems. Indicates a possible problem which the person responsible for the application should be aware of. |
Expected (application) exceptions. For a portlet, this includes non-proxied requests and missing settings. The Oracle WebCenter Interaction Development Kit (IDK) logging service sends a Warn message to the 'EDK main' logging component when it is initialized if verbose logging is enabled, since the network or application administrator should be aware of possible security implications of sending remote call parameters to a cleartext logging channel. |
|
Error |
Used for major problems affecting application function. Indicates a definite problem that should to be corrected. The message should state and explain the problem and suggest how to fix it. |
Unexpected platform exceptions. For a portlet, this includes errors parsing CSP headers. |
|
Fatal |
Used for problems so severe that the application cannot continue to function. The message should state the problem, explain why it is a problem, and suggest how to fix it. Examples include inability to obtain necessary system or network resources. |
A Fatal message is logged when an instance of the class configured for the Web Service object cannot be instantiated. Otherwise reserved for application developer use. |
Table 1-2 Supplemental Logging Levels
| Logging Level | Description | IDK Implementation |
|---|---|---|
|
Action |
Used for significant actions (between Info and Warn in severity). Examples include the beginning or ending of a startup routine or the start or completion of a new user request. |
Initialize an application component or a new remote session. |
|
Function |
Used to bracket the beginning and ending of a function. Use at the very beginning and end of methods to illustrate code paths and provide context for messages occurring between the beginning and ending function messages. |
Dispatching and receiving a remote call, and parsing request parameters. |
|
Performance |
Provides a millisecond timestamp (for example, operation X took # milliseconds). Use to measure operations that may be costly in time. Typically a pair of begin and end performance calls will bracket a blocking call to an operation of interest such as a disk read or write, remote call, external process invocation, database query, or large sort operation. |
PRC remote calls. Web request lifecycle for services. |
To enable Oracle WebCenter Interaction Development Kit (IDK) logging, you must enter the application name and change the settings in the web.xml (Java) or Web.config (.NET) file distributed with the Oracle WebCenter Interaction Development Kit (IDK). The table below lists the applicable variables.
Table 1-3 Oracle WebCenter Interaction Development Kit (IDK) Logging API Web Application Variables
| Setting | Default Value | Description |
|---|---|---|
|
ptedk.LoggingApplicationName |
"" (No logging occurs if the application name is not set.) |
OpenLog and Logging Spy use a text string (OpenLog: 'Application' / PTSpy: 'server') to identify a specific log channel to which log appenders can send messages, and from which log receivers can receive messages. To receive messages sent to an OpenLog channel, a listening application must be configured with the same application name used by the log-generating application. To receive log messages from an existing Oracle WebCenter Interaction Development Kit (IDK) deployment in a Web application, set values for the name and logging options according to the example in the web.xml or Web.config file. To receive log messages from a non-Web application that uses the Oracle WebCenter Interaction Development Kit (IDK) (for example, batch or utility processes using remote APIs), set the logging application name programmatically. Use the value in the key ptedk.LoggingApplicationName to set a matching server name in the logging receiver. Note: If the application is already using OpenLog and also using the Oracle WebCenter Interaction Development Kit (IDK), the code must not attempt to initialize OpenLog with a different application name |
|
ptedk.LogToNetwork |
false (Logs to local machine only.) |
Logging to the network is disabled by default. In this condition, log messages can only be received by OpenLog receiver processes on the local machine, including Logging Spy, the File Logger, or receivers using the OpenLog-Log4J Bridge.Logging can be enabled by setting the value associated with ptedk.LogToNetwork to true in the Web application configuration file. For non-Web applications, you can enable network logging programmatically using the Oracle WebCenter Interaction Development Kit (IDK). |
|
ptedk.VerboseLogging |
false (Does not log method parameters or return values unless requested.) |
Verbose logging is disabled by default. Basic logging messages are still sent to the log receiver. The portlet API sends an Info log message with each new portlet context created (each portlet request). Any exceptions, errors, or requests for missing settings are logged as Error or Warning as appropriate.If you enable verbose logging, additional messages and details are sent to the log receiver. The portlet API sends a Warning message informing the log reader that sensitive information may be logged in cleartext. With each portlet request, the portlet API sends a Debug message with a toString() of the PortletRequest object, containing request parameters and portlet settings; and a Debug message with a toString() of the PortletUser object, containing user settings. |
The Oracle WebCenter Interaction Development Kit (IDK) logging API allows you to send log messages from remote services and applications to a variety of logging receivers.
The com.plumtree.remote.logging package provides two interfaces:
LogFactory provides static methods to configure logging, query configuration properties, and obtain ILogger instances.
ILogger allows you to test if various log levels are enabled and provides logging methods. To create a logger object, call LogFactory.getLogger().
To use the Oracle WebCenter Interaction Development Kit (IDK) Logging API, you must configure the logging receiver to read logs from the IDK. To configure the log receiver, you must know the logging application name. The Oracle WebCenter Interaction Development Kit (IDK) logging application name is configured in the Web application configuration file or set via the initialize() method in the Logging API.
For details on using the logging API, see the following sections:
Using Oracle WebCenter Interaction Development Kit (IDK) Logging in Java
Using Oracle WebCenter Interaction Development Kit (IDK) Logging in .NET
Using Oracle WebCenter Interaction Development Kit (IDK) Logging from the Command Line
This example demonstrates how to enable and use Oracle WebCenter Interaction Development Kit (IDK) logging in a remote Java application.
The first step in this example is to enable logging programmatically, by defining the logging application name and setting the log to network option to true. For details on logging options, see Configuring Java Oracle WebCenter Interaction Development Kit (IDK) Logging (web.xml).
import com.plumtree.remote.logging.ILogger;
import com.plumtree.remote.logging.LogFactory;
public class LoggingExample extends Thread
{
private static final String INSTANCES_COMPONENT_NAME = 'Instances';
private static final String MAIN_LOOP_COMPONENT_NAME = 'Main Loop';
// set the application name
// (legal characters: ASCII alphanumerics plus . - _ and space)
public static final String LOGGING_APPLICATION_NAME = 'Logging_API_Example-1';
// set to true to multicast log messages to local network
// set to false to send message only listeners on local machine
public static final boolean LOG_TO_NETWORK = true;
private ILogger logger; //instance logging class
private static ILogger mainLogger; // main component logging class
Initialize LogFactory. The recommended way to initialize non-web applications is in a static block in the application's main class or a logging utility class. Always check to see if LogFactory has already been initialized (for example, as part of an IDK-based web application).
if (!LogFactory.isInitialized())
{
LogFactory.initialize(LOGGING_APPLICATION_NAME, LOG_TO_NETWORK);
}
System.out.print('Set your logging receiver to the \'server\' or \'application name\' ');
System.out.println(LogFactory.getApplicationName());
System.out.println('The logging component names are \'EDK\', \'' + MAIN_LOOP_COMPONENT_NAME + '\' and \''
+ INSTANCES_COMPONENT_NAME + '\'.');
mainLogger = LogFactory.getLogger(MAIN_LOOP_COMPONENT_NAME, LoggingExample.class);
This code creates the following messages in Logging Spy. These messages are sent automatically by the Oracle WebCenter Interaction Development Kit (IDK). For the sample code above, the <appname> would be "Logging_API_"
1 <#> <app name> <date/time> Info EDK main LogFactory Initiating EDK logging on behalf of EDK: LogFactory.
2 <#> <app name> <date/time> Info EDK main LogFactory Verbose logging of internal EDK classes is off. It may be enabled by setting ptedk.VerboseLogging='true' .
Create an instance of ILogger by calling LogFactory.getLogger. In the code below, the LoggingExample method sends an Info level log message when an instance is created. The snippet below also uses ILogger.functionBegin and ILogger.functionEnd to log when a method is entered and exited, ILogger.action to log significant events, and ILogger.performanceBegin and ILogger.performanceEnd to log the time required to execute the methods.
public LoggingExample(String instanceName)
{
setName(instanceName);
this.logger = LogFactory.getLogger(INSTANCES_COMPONENT_NAME, LoggingExample.class);
mainLogger.info('Created new instance named {0}', instanceName);
}
public static void main(String[] args)
{
final String methodName = 'main';
mainLogger.functionBegin(methodName);
// get a timestamp to measure performance of this function
long performanceStartTicks = mainLogger.performanceBegin();
mainLogger.action('Creating and starting instances');
LoggingExample bill = new LoggingExample('Bill');
bill.start();
LoggingExample larry = new LoggingExample('Larry');
larry.start();
mainLogger.action('Done creating instances');
// send log message with time since performanceBegin
mainLogger.performanceEnd(methodName, performanceStartTicks);
mainLogger.functionEnd(methodName);
}
This code creates the following messages in Logging Spy.
3 <#> <app name> <date/time> Function Main Loop main LoggingExample Entering Function main
4 <#> <app name> <date/time> Action Main Loop main LoggingExample Creating and starting instances
5 <#> <app name> <date/time> Info Main Loop main LoggingExample Created new instance named Bill
6 <#> <app name> <date/time> Info Main Loop main LoggingExample Created new instance named Larry
7 <#> <app name> <date/time> Action Main Loop main LoggingExample Done creating instances
8 <#> <app name> <date/time> Performance Main Loop main LoggingExample main took 0 ms.
9 <#> <app name> <date/time> Function Main Loop main LoggingExample Leaving Function mainInfo
The code below demonstrates available logging levels and provides an example of how to use token substitution in formatting strings to construct messages. The thread runs through a small test of logging messages and transfers work to the next by calling yield(). Note: Wrap any complex message construction in a conditional block to avoid doing work if there are no listeners at that log level.
public void run()
{
String levelDescriptionFormat = '{0} level messages are {1} by default in the log receiver.';
logger.debug(levelDescriptionFormat, 'Debug', 'off');
logger.info(levelDescriptionFormat, 'Info', 'off');
logger.warn(levelDescriptionFormat, 'Warn', 'on');
logger.error(levelDescriptionFormat, 'Error', 'on');
logger.fatal(levelDescriptionFormat, 'Fatal', 'on');
yield();
// Exceptions may also be caught and logged, and may use token substitution
try
{
throw new InterruptedException(getName() + ' was interrupted.');
}
catch (Exception eCaught)
{
logger.warn(eCaught, 'Caught an exception from {0}. ', eCaught.getClass().getPackage().getName());
}
}
This code creates the following messages in Logging Spy:
10 <#> <app name> <date/time> Function Instances Larry LoggingExample Entering Function run
11 <#> <app name> <date/time> Action Instances Bill LoggingExample Action log messages are on by default in the log receiver.
12 <#> <app name> <date/time> Debug Instances Bill LoggingExample Debug level messages are off by default in the log receiver.
13 <#> <app name> <date/time> Info Instances Bill LoggingExample Info level messages are off by default in the log receiver.
14 <#> <app name> <date/time> Warning Instances Bill LoggingExample Warn level messages are on by default in the log receiver.
15 <#> <app name> <date/time> Error Instances Bill LoggingExample Error level messages are on by default in the log receiver.
16 <#> <app name> <date/time> Fatal Instances Bill LoggingExample Fatal level messages are on by default in the log receiver.
17 <#> <app name> <date/time> Action Instances Larry LoggingExample Action log messages are on by default in the log receiver.
18 <#> <app name> <date/time> Debug Instances Larry LoggingExample Debug level messages are off by default in the log receiver.
19 <#> <app name> <date/time> Info Instances Larry LoggingExample Info level messages are off by default in the log receiver.
20 <#> <app name> <date/time> Warning Instances Larry LoggingExample Warn level messages are on by default in the log receiver.
21 <#> <app name> <date/time> Error Instances Larry LoggingExample Error level messages are on by default in the log receiver.
22 <#> <app name> <date/time> Fatal Instances Larry LoggingExample Fatal level messages are on by default in the log receiver.
23 <#> <app name> <date/time> Warning Instances Bill LoggingExample Caught an exception from - java.lang. java.lang.InterruptedException: Bill was interrupted. - java.lang.InterruptedException: Bill was interrupted. at - com.plumtree.remote.logging.example.LoggingExample.run(LoggingExample.java:110)
24 <#> <app name> <date/time> Warning Instances Larry LoggingExample Caught an exception from - java.lang. java.lang.InterruptedException: Larry was interrupted. - java.lang.InterruptedException: Larry was interrupted. at - com.plumtree.remote.logging.example.LoggingExample.run(LoggingExample.java:110)
This example demonstrates how to use Oracle WebCenter Interaction Development Kit (IDK) logging in a remote .NET application.
The first step in this example is to enable logging programmatically, by defining the logging application name and setting the log to network option to true. For details on logging options, see Configuring .NET Oracle WebCenter Interaction Development Kit (IDK) Logging (Web.config).
using System;
using System.Threading;
using Plumtree.Remote.Logging;
public class LoggingCommandLineExample
{
private static readonly String INSTANCES_COMPONENT_NAME = 'Instances';
private static readonly String MAIN_LOOP_COMPONENT_NAME = 'Main Loop';
// set the application name
// (legal characters: ASCII alphanumerics plus . - _ and space)
public static readonly String LOGGING_APPLICATION_NAME = 'Logging_API_Example-1';
// set to true to multicast log messages to local network
// set to false to send message only listeners on local machine
public static readonly bool LOG_TO_NETWORK = true;
private ILogger logger; //instance logging class
private static ILogger mainLogger; // main component logging class
// thread for each instance of LoggingCommandLineExample
private Thread _thread;
Initialize LogFactory. The recommended way to initialize non-web applications is in a static block in the application's main class or a logging utility class. Always check to see if LogFactory has already been initialized (for example, as part of an IDK-based web application).
if (!LogFactory.isInitialized())
{
LogFactory.Initialize(LOGGING_APPLICATION_NAME, LOG_TO_NETWORK);
}
Console.Out.WriteLine('Set your logging receiver to the \'server\' or \'application name\' ');
Console.Out.WriteLine(LogFactory.GetApplicationName());
Console.Out.WriteLine('The logging component names are \'EDK\', \'' + MAIN_LOOP_COMPONENT_NAME + '\' and \'' +
INSTANCES_COMPONENT_NAME + '\'.');
mainLogger = LogFactory.GetLogger(MAIN_LOOP_COMPONENT_NAME, typeof(LoggingCommandLineExample));
This code creates the following messages in Logging Spy. These messages are sent automatically by the Oracle WebCenter Interaction Development Kit (IDK). For the sample code above, the <app name> entry would be "Logging_API_"
1 <#> <app name> <date/time> Info EDK main LogFactory Initiating EDK logging on behalf of EDK: LogFactory.
2 <#> <app name> <date/time> Info EDK main LogFactory Verbose logging of internal EDK classes is off. It may be enabled by setting ptedk.VerboseLogging='true' .
Create an instance of ILogger by calling LogFactory.getLogger. In the code below, the LoggingExample method sends an Info level log message when an instance is created. The snippet below also uses ILogger.functionBegin and ILogger.functionEnd to log when a method is entered and exited, ILogger.action to log significant events, and ILogger.performanceBegin and ILogger.performanceEnd to log the time required to execute the methods.
public LoggingCommandLineExample(String instanceName)
{
_thread = new Thread(new ThreadStart(Run));
_thread.Name = instanceName;
this.logger = LogFactory.GetLogger(INSTANCES_COMPONENT_NAME, typeof(LoggingCommandLineExample));
mainLogger.Info('Created new instance named {0}', instanceName);
}
[STAThread]
public static void main(String[] args)
{
String methodName = 'main';
mainLogger.FunctionBegin(methodName);
// get a timestamp to measure performance of this function
long performanceStartTicks = mainLogger.PerformanceBegin();
mainLogger.Action('Creating and starting instances');
LoggingExample bill = new LoggingExample('Bill');
bill.Thread.Start();
LoggingExample larry = new LoggingExample('Larry');
larry.Thread.Start();
mainLogger.Action('Done creating instances');
// send log message with time since performanceBegin
mainLogger.PerformanceEnd(methodName, performanceStartTicks);
mainLogger.FunctionEnd(methodName);
}
This code creates the following messages in Logging Spy.
3 <#> <app name> <date/time> Function Main Loop main LoggingExample Entering Function main
4 <#> <app name> <date/time> Action Main Loop main LoggingExample Creating and starting instances
5 <#> <app name> <date/time> Info Main Loop main LoggingExample Created new instance named Bill
6 <#> <app name> <date/time> Info Main Loop main LoggingExample Created new instance named Larry
7 <#> <app name> <date/time> Action Main Loop main LoggingExample Done creating instances
8 <#> <app name> <date/time> Performance Main Loop main LoggingExample main took 0 ms.
9 <#> <app name> <date/time> Function Main Loop main LoggingExample Leaving Function mainInfo
The code below demonstrates available logging levels and provides an example of how to use token substitution in formatting strings to construct messages. The thread runs through a small test of logging messages and interleaves the messages using Thread.Sleep.
Note:
Wrap any complex message construction in a conditional block to avoid doing work if there are no listeners at that log level.
public void Run()
{
String methodName = 'run';
// send log message that function is starting
logger.FunctionBegin(methodName);
// get a timestamp to measure performance of this function
long performanceStartTicks = mainLogger.PerformanceBegin();
Thread.Sleep(1); // interleaves work to the other thread
String levelDescriptionFormat = '{0} level messages are {1} by default in the log receiver.';
logger.Debug(levelDescriptionFormat, 'Debug', 'off');
logger.Info(levelDescriptionFormat, 'Info', 'off');
logger.Warn(levelDescriptionFormat, 'Warn', 'on');
logger.Error(levelDescriptionFormat, 'Error', 'on');
logger.Fatal(levelDescriptionFormat, 'Fatal', 'on');
Thread.Sleep(1); // interleaves work to the other thread
// Exceptions may also be caught and logged, and may use token substitution
try
{
throw new ThreadInterruptedException(_thread.Name + ' was interrupted.');
}
catch (Exception eCaught)
{
logger.Warn(eCaught, 'Caught an exception from {0}. ', eCaught.GetType().Name);
}
Thread.Sleep(1); // interleaves work to the other thread
// send log message with time since performanceBegin
mainLogger.PerformanceEnd(methodName, performanceStartTicks);
// send log message that function is ending
logger.FunctionEnd(methodName);
}
public Thread Thread
{
get
{
return _thread;
}
}
This code creates the following messages in Logging Spy:
10 <#> <app name> <date/time> Function Instances Larry LoggingExample Entering Function run
11 <#> <app name> <date/time> Action Instances Bill LoggingExample Action log messages are on by default in the log receiver.
12 <#> <app name> <date/time> Debug Instances Bill LoggingExample Debug level messages are off by default in the log receiver.
13 <#> <app name> <date/time> Info Instances Bill LoggingExample Info level messages are off by default in the log receiver.
14 <#> <app name> <date/time> Warning Instances Bill LoggingExample Warn level messages are on by default in the log receiver.
15 <#> <app name> <date/time> Error Instances Bill LoggingExample Error level messages are on by default in the log receiver.
16 <#> <app name> <date/time> Fatal Instances Bill LoggingExample Fatal level messages are on by default in the log receiver.
17 <#> <app name> <date/time> Action Instances Larry LoggingExample Action log messages are on by default in the log receiver.
18 <#> <app name> <date/time> Debug Instances Larry LoggingExample Debug level messages are off by default in the log receiver.
19 <#> <app name> <date/time> Info Instances Larry LoggingExample Info level messages are off by default in the log receiver.
20 <#> <app name> <date/time> Warning Instances Larry LoggingExample Warn level messages are on by default in the log receiver.
21 <#> <app name> <date/time> Error Instances Larry LoggingExample Error level messages are on by default in the log receiver.
22 <#> <app name> <date/time> Fatal Instances Larry LoggingExample Fatal level messages are on by default in the log receiver.
23 <#> <app name> <date/time> Warning Instances Bill LoggingExample Caught an exception from - java.lang. java.lang.InterruptedException: Bill was interrupted. - java.lang.InterruptedException: Bill was interrupted. at - com.plumtree.remote.logging.example.LoggingExample.run(LoggingExample.java:110)
24 <#> <app name> <date/time> Warning Instances Larry LoggingExample Caught an exception from - java.lang. java.lang.InterruptedException: Larry was interrupted. - java.lang.InterruptedException: Larry was interrupted. at - com.plumtree.remote.logging.example.LoggingExample.run(LoggingExample.java:110)
These instructions explain how to run the Oracle WebCenter Interaction Development Kit (IDK) Logging API example code (Java or .NET) from the command line.
Scan the sample code and note the LOGGING_APPLICATION_NAME parameter declared near the top of the class. Change this value if you wish, and record it.
Java: Compile with all the idk jar files in the classpath. Make sure servlet.jar and all idk jar files are in the classpath. .NET: Compile the source with reference to idk.dll and its supporting DLLs.
Launch Logging Spy. Go to the Filters dialog box and add a new server (right-click and select Add Server ). Enter the value set for LOGGING_APPLICATION_NAME in the Add Server dialog box and click OK . Wait a few seconds until a new entry appears in the Filter Settings list .
Run the example from the command line. Note any messages displayed in Logging Spy. Error and exception logs are included in the logging demonstration.
Go back to the Filters dialog in Logging Spy. Click the gray selection box beside the 'server' entry to accept logging for all logging levels.
Run the example again. Note that the messages displayed now in Logging Spy include examples of all logging levels, including error and exception logs.
Oracle WebCenter Interaction acts as a gateway server, brokering transactions between client computers and external resources.
Services on external resources communicate with Oracle WebCenter Interaction via HTTP and SOAP as shown in the simplified diagram below. For example, when a browser requests a page, Oracle WebCenter Interaction makes simultaneous requests to each external resource to retrieve the portlet content for the page. The external resource reads the current user's preferences from the HTTP headers sent by Oracle WebCenter Interaction and sends back the appropriate HTML. Oracle WebCenter Interaction inserts the HTML into the table that makes up the page. Any images stored in the Image Service are retrieved and displayed by the browser.
Figure 1-1 Server Communication (Simplified Diagram)
HTTP and SOAP are both necessary because each standard fits the specific needs of different tasks. SOAP involves posting and returning XML documents and is appropriate for exchanging highly structured data. SOAP is used in the server-to-server communication required for content services, identity services, and importing documents. HTTP is a much more lightweight protocol, used in Oracle WebCenter Interaction for UI presentation, basic configuration and click-through, and caching. For an introduction to SOAP, see SOAP.
CSP is a platform-independent protocol based on the open standard of HTTP 1.1. The syntax of communication between Oracle WebCenter Interaction and external resources is defined by CSP. CSP defines custom headers and outlines how services use HTTP to communicate and modify settings. For details on CSP, see HTTP and CSP.
A gateway server acts as a middleman, brokering transactions between a client computer and another server. This configuration is typically used to serve content to clients that would otherwise be unable to access the external resource, but it can be used to impose additional security restrictions on the client. The gateway hides the external resource; to the end user, the content appears to come directly from the gateway server.
This architecture makes Oracle WebCenter Interaction the single point of access for content, and allows external resources to reside on a private network or behind a firewall. As long as Oracle WebCenter Interaction can connect to the external resource, users can view the content, even if they cannot access it directly. To the browser, Oracle WebCenter Interaction appears to be the source of content on the external resource.
When a user interacts with a service, any request made to a URL in the gateway is automatically rerouted through Oracle WebCenter Interaction. To the user, the content appears to come from Oracle WebCenter Interaction; the remote server is an unknown back-end system.
There are many benefits to this configuration. The most useful to services are:
Dynamic functionality and personalization: Oracle WebCenter Interaction intercepts requests from portlets, which allows it to include information stored in the database in HTTP requests and responses. Most of this information is accessible through Oracle WebCenter Interaction Development Kit (IDK) methods. In many situations, an adaptive tag provides the functionality required, including navigation and login elements. Custom tags can be created for additional functionality.
Security: Services can allow users to access content that is not publicly available. Files stored on a secure server can be made available by including specific URLs in the configuration of the gateway. Note: The gateway is a powerful feature, and can compromise security if incorrectly configured. Allowing direct access to a remote server that hosts unprotected private content could create a dangerous security hole.
Performance: Oracle WebCenter Interaction caches proxied content, decreasing response time for end users and improving performance on the remote server. While gatewaying works efficiently for content like HTML, it is generally not appropriate for binary data like static images. Images do not need to be transformed, and gatewaying large images can adversely affect performance. This is one reason the Image Service should be used to prevent routing static images through the gateway.
The collection of URLs that should be gatewayed for a service is configured in the Web Service editor on the HTTP Configuration page. In the Gateway URL Prefixes list, you must enter the base URLs for any directories that should be gatewayed.
Keep the following warnings and best practices in mind when implementing services that use the gateway:
URL transformation: Oracle WebCenter Interaction must transform code so that proxied URLs open correctly. Before Oracle WebCenter Interaction sends a response, it parses the HTML and looks for any URLs that use the Internal URL prefix configured for the associated Web Service. Oracle WebCenter Interaction transforms any URLs that should be proxied before returning the response to the client. Relative URLs are transformed to point to the correct location.
Scripting limitations: JavaScript constructs that dynamically create URLs can cause problems, because they are run after content is already transformed. VBScript is not transformed by the gateway; you can continue to use dynamic scripts and VBScript as long as your code is gateway-aware. To manually mark a URL for transformation, use the pt:url tag. To disable transformation, use pt:transformer with a pt:fixurl attribute of 'off.' For details, see Adaptive Tags.
URL encoding: It is a best practice to encode all headers that are URLs to prevent unexpected transformation. In JSP, encode all URLs that are written. If the code writes URLs in the body of a page (for example, a link to a preferences page) it should be encoded. The standard Java servlet command response.encodeURL() is the preferred method, but you can also use URLEncoder.encode(url). In the .NET Framework, the HttpUtility.URLEncode class provides the necessary functionality. Note: In .NET, there is no need to encode the redirect URL; this is handled automatically on the back end.
All portlets are designed to be displayed with other portlets. As explained in the previous section, Oracle WebCenter Interaction acts as a gateway, processing and combining portlets from multiple applications to create a single, unified page with a range of functionality.
The code returned by a portlet is parsed by the gateway server and inserted into the appropriate cell in the HTML table that makes up the mashup page. Portlets from the same back-end application can interact with each other within the page.
Figure 1-3 Oracle WebCenter Interaction as Gateway Server
In Oracle WebCenter Interaction, the portal page defines the layout and includes specific portlets in the page using adaptive tags. Header navigation can be added using tags.
HTTP is a protocol used mostly for transferring web page content and XML between a server and a client. CSP is a platform-independent protocol based on the open standard of HTTP 1.1 that defines the syntax of communication between Oracle WebCenter Interaction and remote servers.
HTTP communication is made up of Requests and Responses. Requests and Responses are essentially lists of name-value pairs of metadata in headers, along with an optional body. The body is the data that is being transferred (an HTML page or XML file). The metadata in the headers is information about the Request or Response itself (what language the content is in, or how long the browser should cache it). The Request and Response each contain specific information, outlined next. For more detailed information on HTTP, see RFC 2616 (http://www.faqs.org/rfcs/rfc2616.html).
The client sends the server an HTTP Request, asking for content. The Request body is used only for requests that transfer data to the server, such as POST and PUT.
HTTP Request Format:
[METHOD] [REQUEST-URI] HTTP/[VERSION] [fieldname1]: [field-value1] [fieldname2]: [field-value2] [request body, if any]
HTTP Request Example:
GET /index.html HTTP/1.1 Host: www.plumtree.com User-Agent: Mozilla/3.0 (compatible; Opera/3.0; Windows 95/NT4) Accept: */* Cookie: username=JoeSmith
The server sends back an HTTP Response that contains page content and important details, such as the content type, when the document was last modified, and the server type. The Response contains an error message if the requested content is not found.
HTTP Response Format:
HTTP/[VERSION] [CODE] [TEXT] [fieldname1]: [field-value1] [fieldname2]: [field-value2] [response body, if any (document content here)]
HTTP Response Example:
HTTP/1.0 200 Found Last-modified: Thursday, 20-Nov-97 10:44:53 Content-length: 6372 Content-type: text/html <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 3.2 Final// EN'><HTML> ...followed by document content...
Custom HTTP headers can be configured to include specialized information.
Note:
Header size limits are controlled by the server that hosts the code. The standard limit for IIS/ASP is 60K. Java Application Servers range from 2K to 10K. These limits are generally configurable; see your server documentation for details.
Services can also access standard HTTP headers, such as the Set-Cookie header or HTTP 1.1 basic authentication header. If you want to investigate HTTP further, you can view all the headers being passed back and forth between your browser and Web server using a tunnel tool. HTTP is used in conjunction with SSL to serve up secure content. Single Sign-On (SSO) also uses HTTP headers for basic authentication.
CSP extends HTTP and defines proprietary headers to pass settings between Oracle WebCenter Interaction.) and remote servers. CSP outlines how Oracle WebCenter Interaction services use HTTP to communicate and modify settings. (CSP is also used by Oracle WebCenter Interaction.)
The current version is CSP 1.4, which includes backward compatibility with previous versions. For links to the latest versions of the CSP specification, see Appendix B, "Additional Development References".
The Oracle WebCenter Interaction Development Kit (IDK) provides simplified, stable interfaces that allow you to write code that communicates using CSP.
Oracle WebCenter Interaction uses a group of custom headers to communicate system and user configuration variables. These headers include information that can be used by services.
All the usefulinformation stored in these headers should be accessed using the Oracle WebCenter Interaction Development Kit (IDK). Additional proprietary headers contain the protocol version, gateway type, and aggregationmode. All the key information in these headers is accessible through the IPortletUser and IPortletRequest interfaces in the IDK.
Table 1-4 Oracle WebCenter Interaction Headers
| Header Name | IDK Method | Description |
|---|---|---|
|
User ID |
|
The User ID of the currently logged in user. This value can be used to determine if the session has expired. If UserID=2, the default 'Guest' user is logged in; any other user's session has ended. |
|
User Name |
|
The name of the logged in user. The user's name can be used to personalize display or pre-fill form fields. |
|
Locale |
|
The current user's language and character set. This value is essential when determining the correct content to return in an internationalized implementation. |
|
Time Zone |
|
The time zone of the current user in the format used by Oracle WebCenter Interaction. This value can be used to synchronize remote server time with Oracle WebCenter Interaction. |
|
Image Service URL |
|
The URL to the root virtual directory of the Image Service in the user's implementation of Oracle WebCenter Interaction. This location should be used for all static images used in services. |
|
Stylesheet URL |
|
The URL to the current user's style sheet. In each implementation of Oracle WebCenter Interaction, the UI is customized. In some portals, users can choose between a selection of stylesheets. Using these styles ensures that portlets appear in the style of the current user's implementation of Oracle WebCenter Interaction. |
|
Page ID |
|
The Page ID for the current portal page. This value allows a single portlet to display different content on different pages. |
|
Portlet ID |
|
The ID for the current portlet. This value is useful for appending to the names of HTML forms and client-side JavaScript functions to ensure unique form and function names on the page to avoid name conflicts. |
|
Return URL |
|
The URL to the page that the portlet should return to when finished, usually the page that hosts the portlet. Note that if the user has navigated to another page in the portal, this URL will be the last personal or community page that the user visited. Preference pages need this URL to return the user to the correct page after settings are configured. |
|
Content Mode |
|
The current content mode. This value is used to display portlet content in the appropriate manner. |
|
Browser Type |
|
The type of device being used to access Oracle WebCenter Interaction. Oracle WebCenter Interaction can support wireless handheld devices that communicate with HDML, WML, or HTML. |
SOAP is a text-based protocol to wrap XML data for any type of transport, providing an efficient way to communicate structured data.
The SOAP 1.1 specification describes SOAP as follows: "SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses."
SOAP is based on web standards. Like HTML, SOAP uses tags to indicate the role of each piece of information. In most implementations, SOAP uses HTTP for its transport protocol. A SOAP request is an XML document that describes a method to invoke on a remote machine and any parameters to be used. A program sends a SOAP request to a SOAP server. The SOAP server tries to execute the method with the parameters it was passed, and it sends back a SOAP response (the result or an error message). A SOAP endpoint is an HTTP-based URL identifying a target for method invocation.
A common analogy illustrates this concept well. If your XML code was a letter, SOAP would be the envelope; like an envelope, SOAP protects content from unauthorized access and provides information about the sender and the addressee. All the elements of the SOAP envelope are defined by a schema. The schema URI is also the identifier for the SOAP envelope namespace: http://schema.xmlsoap.org/soap/envelope.
As in standard XML, SOAP uses namespaces to segregate content. The formal designation of a namespace is a URI, usually a URL. Namespaces ensure unique element references, and they allow a processor to pick out which instructions it should obey and treat instructions for other processors as simple data. Processors are set up to handle elements from a particular namespace. Elements that have no namespace are treated as data.
SOAP Message in HTTP Request:
POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset='utf-8' Content-Length: nnnn SOAPAction: 'Some-URI' <SOAP-ENV:Envelope xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/' SOAP-ENV:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m='Some-URI'> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
SOAP Message in HTTP Response:
HTTP/1.1 200 OK Content-Type: text/xml; charset='utf-8' Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/' SOAP-ENV:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m='Some-URI'> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Download the complete SOAP 1.1 specification from the World Wide Web Consortium at http://www.w3c.org/TR/SOAP/.
The Oracle WebCenter Interaction SOAP API exposes commonly used elements of the traditional Oracle WebCenter Interaction API, focused on the functions required to develop applications that access portal users, communities, portlets, and directory functions. The Oracle WebCenter Interaction Development Kit (IDK) PRC API provides an efficient, object-oriented way to call into Oracle WebCenter Interaction's SOAP API. For details, see Chapter 2, "Oracle WebCenter Interaction Development Kit (IDK) Programmable Remote Client (PRC) Remote APIs".
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
