How you call a business process from another application depends on your business requirements, including whether the client is in the same application as the business process it calls, and whether the client is a Oracle Workshop for WebLogic component, such as a Web service (JWS), business process (JPD), or pageflow (JPF). To learn about invoking business processes, see the following topics:
Business Processes can expose their functionality to clients in several ways, including through WSDL files, Process Controls, Service Broker Controls, and Business Process (Process.java) Proxies.
You can only use Process controls and Service Broker controls between Oracle Workshop for WebLogic components: Web services (JWS), business processes (Process.java), or pageflows (JPF).
The Process control allows a Web service, business process, or pageflow to send requests to, and receive callbacks from, a business process. Process control invocations are Java Remote Method Invocation (RMI) calls. The target business process must be hosted on the same Oracle WebLogic Server domain as the caller. The Process control is typically used to call a subprocess from a parent business process. Transaction contexts are propagated from the parent processes to the subprocesses over the Process control calls. In other words, the target business process runs in the same transaction as the caller.
The Service Broker control allows a business process or Web service to invoke and receive callbacks from another service using one of several protocols; the most commonly used protocol is SOAP over HTTP. (To learn about the protocols, see Using Dynamic Binding.) The target service must expose a WSDL interface; it can be a business process, Web service, or remote (non-Workshop) Web service. Because the transport used is HTTP or JMS, the transaction contexts are not propagated over the Service Broker control calls. Typically, the Service Broker control calls are to remote services.
To call business processes from non-Workshop clients, use a JPD Proxy. You can use a JPD Proxy to communicate with a business process from any Java code. When you invoke a business process using a JPD Proxy, the calls are Java RMI calls. Transaction contexts are propagated from the client to the business process over the JPD Proxy calls. In other words, if the client has a transaction context, the target business process runs in the same transaction as the client. JPD Proxies are typically used by non-Workshop J2EE clients or standalone Java clients to invoke business processes.
Depending on the nature of the client and where it is with respect to the target business processes, clients call the business processes in different ways. The following sections describe the scenarios:
If the client is a Workshop client (a Web service, a business process, or a pageflow) and the target business process is in a different domain than the client, use a Service Broker control. In this case, create a Service Broker control from the target business process and call the business process using that control. To learn how to create and use Service Broker controls, see Service Broker Control.
You can also use a JPD Proxy in this case. To learn how, see How Do I: Use a JPD Proxy to a Call Business Process?
If the client is a Workshop client (a Web service, a business process, or a pageflow) and the target business process is in the same Oracle Workshop for WebLogic application, we recommend that you use a Process control. That is, create a Process control from the target business process and call the business process using that control. To learn how to create and use Process controls, see Process Control.
You can also use a Service Broker control in this case. To learn how, see Service Broker Control.
If the client is a standalone Java program, a non-workshop J2EE client (EJB, servlet, or JSP), use a JPD Proxy to call the target business process. To learn how, see How Do I: Use a JPD Proxy to a Call Business Process?
Because JPD Proxy calls are RMI calls, the client and the target business process must be in the same organization.
WARNING: | Business processes that include client callbacks send those callbacks to the client that started the process. JPD Proxies cannot receive callbacks from business processes. An error will occur in your business process if a client uses a JPD Proxy to start a business process that includes client callbacks; the business process fails at run time when it tries to send the callback to the client (the JPD Proxy) that started it. |
You can use a JPD Proxy to call any business process (synchronous and asynchronous, stateful, and stateless) from any Java client, including standalone Java applications, EJBs, JSPs and Servlets. Using a Java proxy for a business process requires different steps depending on whether the client application that uses the proxy is in the same JVM as the target business process.
This topic includes the following sections:
A JPD Proxy is an RMI client to a business process (JPD). An interface that matches a business process’ client requests is associated with each business process. This interface is called the JPD public contract. Each method on the JPD public contract has the same signature as the corresponding client request. A JPD Proxy is a JAR that contains the compiled class file for the JPD contract. You can use the class file to access the JPD as though it were a local Java class. JPD Proxy calls are over Java RMI. JPD Proxy calls propagate the transaction context from the clients to the business processes.
You can download the JPD Proxy JAR file from the JPD Proxy link on the Oracle Workshop for WebLogic Test Browser Overview page (see How Do I: Get a JPD Proxy for a Business Process?).
WARNING: | Business processes that include client callbacks send those callbacks to the client that started the process. JPD Proxies cannot receive callbacks from business processes. An error will occur in your business process if a client uses a JPD Proxy to start a business process that includes client callbacks; the business process fails at run time when it tries to send the callback to the client (the JPD Proxy) that started it. |
The JpdProxy
class is a factory class for proxies to a Oracle WebLogic Integration business process type. Clients call one of the create()
methods on the class to get a proxy instance. The create()
methods take the JPD contract class (java.lang.Class
) as input.
An example JPD contract interface for a business process named RequestQuote.java
is shown in the following listing.
package weblogic.wli.jpdproxy;
import org.example.request.QuoteRequestDocument;
public interface RequestQuote {
public void quoteRequest(org.example.request.QuoteRequestDocument requestXML);
public static final String SERVICE_URI =
"/myApplication/requestquote/RequestQuote.jpd";
}
Note the following characteristics in the preceding example contract interface:
RequestQuoteProxy.jar
that contains a class file named RequestQuote.class
).public void quoteRequest(org.example.request.QuoteRequestDocument requestXML)
. Note: | When you write your client application, you can determine which client request methods are available for you to use through the JPD Proxy by reviewing the source code for the business process. To do so, ensure that the business process (JPD) is open in the Oracle Workshop for WebLogic graphical design environment, identify the Client Request calls in the Design view, then open the Source view to view the method names and signatures. |
requestXML
, which is of type QuoteRequestDocument
.SERVICE_URI
static final field. The String value of the SERVICE_URI
field is the URI for the business process at the time the JPD Proxy is downloaded from the Oracle Workshop for WebLogic test browser. The client can pass this constant to the create
method, or can pass a different value.
A different value for SERVICE_URI
is required if the business process (JPD) is deployed to a different location after the JPD Proxy JAR was generated. For example, you can create the JPD Proxy from the business process while the process is deployed in a development environment. Subsequently, the business process can be moved to a different location for production. Therefore, the business process is accessible through a different URI; clients must pass the new URI value to the create method.
If the Oracle WebLogic Server is not running, a window is displayed asking if you want to start your server. To start the server, click OK.
Note: | To learn about generating JPD Proxies for business processes that are versioned, see About Versioned Business Processes. |
Note: | By default, the package is weblogic.wli.jpdproxy . If you want to specify a different package for the generated JPD Proxy, enter a package name in the Java package field associated with the JPD Proxy button. |
Save the JAR file to one of the following directories:
WEB-INF/lib
—Save the JAR to the WEB-INF/lib
directory of the Web application from which you want to use the proxy (the client application). In the Oracle Workshop for WebLogic graphical design environment, the JAR file is displayed in the WEB-INF/lib
folder on the Package Explorer pane.
APP-INF/lib
—If you want to use the JPD Proxy JAR from more than one project in your (client) application, save the JAR to the APP-INF/lib
directory at the root of your application. In the Oracle Workshop for WebLogic graphical design environment, the JAR file is displayed in the Libraries
folder at the root of your application in the Package Explorer pane.
If you are using the JPD Proxy from a standalone Java client (outside of Oracle WebLogic Server), save the JAR to any location that is convenient for your client Java application and add the JAR to the client’s CLASSPATH
environment variable.
Note: | The default name of the JAR file is <business-process-name> Proxy.jar , where business-process-name represents the name of the business process for which you are generating the JPD Proxy. Accept the default name unless it conflicts with an existing JAR file. |
CLASSPATH
environment variable:<business-process-name>Proxy.jar
—The JPD Proxy you downloaded from the Oracle Workshop for WebLogic Test Browser (where business-process-name
represents the name of the business process for which you generated the JPD Proxy).jpdproxy_client.jar
—A support JAR that contains business process-independent client-side classes. It is located in the following directory in your Oracle WebLogic installation:BEA_HOME
\wli_10.3\lib
In the preceding line, BEA_HOME
represents the location where you installed Oracle WebLogic Integration.
This JAR contains an abstract proxy-factory class called JpdProxy
, a proxy implementation JpdProxyImpl
, and other client-side run-time classes.
Schemas.jar
—If the JPD Proxy (<business-process-name>
Proxy.jar
) file you downloaded contains references to strongly typed XML or MFL arguments, add the Schemas
.jar
file to the classpath. (Schemas
represents the name you gave to the Schemas project in your application.) The Schemas
.jar
file is available in APP-INF\lib at the root of your application.weblogic.jar
—This file is available in the following location in your installation: BEA_HOME\wlserver_10.3\server\lib
.wlcipher.jar
—If you are using a client with two-way SSL, add this JAR to the CLASSPATH
. The wlcipher.jar
is available in the following location in your installation: BEA_HOME\wlserver_10.3\server\lib
.If the target business process is versioned, you can run the active version of the process to invoke the Test Browser (in this case, the Test Browser is opened on the virtual URI) or you can run any other version of the process (in which case the Test Browser is opened on a specific physical URI). To learn about creating versions of business processes, see Versioning Business Processes.
If you subsequently download a JPD Proxy from the Test Browser, its JPD contract interface matches the virtual JPD or the physical JPD, accordingly. When you create a Java client, you pass the JPD contract and a service URI to the proxy factory method. In most cases the JPD contract interfaces for all versions of a business process are identical, but a specific version of a business process can extend the public interface of the original process. In this case, you must ensure that the service URI and JPD contract interface passed to the proxy factory method are consistent.
This section uses example code to describe how to use a JPD Proxy from a Java client. It includes the following topics:
This topic describes how to use a JPD Proxy from a Java client. The code listing in Listing 29-2 is an example of a Java client that invokes a business process using a JPD Proxy. This example includes basic username-password authentication. A second example ( Listing 29-5) describes how to add two-way SSL to the Java client.
You obtain the JPD Proxy JAR for the business process by first running the purchase order business process in Oracle Workshop for WebLogic to invoke the Test Browser. Then select the JPD Proxy link on the Overview page of the Test Browser.
The following sections reference the code example in Example Java Client to describe how a JPD Proxy Client is used from a Java client:
The code listing in
Listing 29-2 is an example of a Java client that invokes a business process using a JPD Proxy. It invokes a business process named PoRequest.java
. This example includes basic username-password authentication. A second example (
Listing 29-5) describes how to add two-way SSL to the Java client.
package your.package;
// Proxy classes are located in the com.bea.wli.bpm.proxy package.
import com.bea.wli.bpm.proxy.JpdProxy;
import com.bea.wli.bpm.proxy.JpdProxySession;
import weblogic.wli.jpdproxy.PoProcess;
/**
* Import any packages required for your application. For example, if the business
* process uses XML Beans, you must import the appropriate packages.
*/
import requisitionpo.www.purchase.PurchaseDocument;
import requisitionpo.www.purchaserequestreq.PurchaseRequestReqDocument
import javax.naming.Context;
import javax.naming.NamingException;
import javax.naming.InitialContext;
import weblogic.jndi.Environment;
import java.io.*;
public class startPoProcess
{
public static void main(String[] args)
{
try
{
PoProcess p = (PoProcess)
JpdProxy.create(
PoProcess.class,
PoProcess.SERVICE_URI,
new JpdProxy.ContextHandler()
{
public Context getContext() throws NamingException
{
Environment env = new Environment();
env.setProviderUrl("t3://localhost:7001");
env.setSecurityPrincipal("weblogic");
env.setSecurityCredentials("weblogic");
return env.getInitialContext();
}
});
PoDocument document = PoDocument.Factory.newInstance();
Po po = document.addNewPo();
po.setSku("abc");
PoReferenceDocument ref = p.processPO(document);
p.done();
}
catch (Exception e) { ... }
}
}
Note that the following packages are imported in our example Java client:
import com.bea.wli.bpm.proxy.JpdProxy;
import com.bea.wli.bpm.proxy.JpdProxySession;
Proxy classes are located in the com.bea.wli.bpm.proxy
package. Clients can typecast proxies returned by JpdProxy.create()
to JpdProxySession
to set and get the conversation ID that is used when a business process is invoked. To learn about setting and getting conversation IDs, see
About Conversation Management.
The proxy factory method (JpdProxy.create()
) provides two signatures: one to use when the client is running in the same Oracle WebLogic Server domain as the target business process (JPD), the other to use when the client is running in a different domain than the target business process:
The JpdProxy.create()
method creates a client proxy for a business process (JPD). JpdProxy.create()
accepts the public-contract interface that describes the methods of the JPD as input. The result of this call can be typecast to the public contract class. A service URI uniquely identifies the business process (JPD) on the server.
Use the following method when the client is running on the same WLS domain as the target JPD.
public static final Object create(Class publicContract, String serviceUri)
throws JpdProxyException
In the preceding code listing:
Note: | In most cases, the public-contract interfaces for all versions of a business process are identical, but a specific version of a business process can extend the public interface of the original process. In this case, you must ensure that the service URI and JPD contract interface passed to the proxy factory method are consistent. To learn about generating JPD Proxies for versioned business processes, see About Versioned Business Processes. |
This method signature is shown in Listing 29-4, and is used in the example code in Listing 29-2.
The JpdProxy.create()
method creates a client proxy for a business process (JPD). JpdProxy.create()
accepts, as input, the public contract interface that describes the methods of the business process. The result of this call can be typecast to the public-contract class. A service URI uniquely identifies the business process on the server. For the case in which your client is running in a different domain than the target JPD, the JpdProxy.ContextHandler
is invoked by the proxy to obtain the JNDI context used to login to the server and lookup server-side resources.
If you use the version of JpdProxy.create()
that does not take a ContextHandler
, the client’s JNDI context is used to look up the ProxyDispatcher
EJB.
You need a ContextHandler
in the following scenarios:
Note: | The ProxyDispatcher EJB is a Oracle WebLogic Integration system stateless session bean that handles incoming requests from JPD Proxies. Its scope is the Oracle WebLogic Server domain. ProxyDispatcher is targeted to all managed servers in a cluster. Administrators can set authentication and authorization policies on this EJB using the Oracle WebLogic Server Administration Console. Oracle recommends using the Java Authentication and Authorization Service (JAAS) rather than JNDI to associate a User with a security context. To learn more, see the following Oracle WebLogic Server documentation: |
Note: | Oracle WebLogic JNDI |
Note: | Using JAAS Authentication in Java Clients |
Note: | The JpdProxy implementation does not explicitly authenticate to the server. Instead, it relies on JNDI authentication when it looks up the ProxyDispatcherHome with the JNDI context returned by the ContextHandler. |
Use the following method when you need a ContextHandler
:
public static final Object create(Class publicContract, String serviceUri,
JpdProxy.ContextHandler ch) throws JpdProxyException
In the preceding code listing:
publicContract
specifies the public contract interface of the JPD.serviceUri
specifies the URI of the JPD. ch
specifies a context handler. Clients pass an instance of this JpdProxy.ContextHandler
interface to the create method and the proxy implementation uses this instance at run time to allocate a JNDI context. This context is used to login to the server and look up server side resources that handle incoming proxy requests.
Listing 29-2 shows the getContext()
method used in the Java client.
To learn more about the context handler interface, see Interface JpdProxy.ContextHandler in the Oracle WebLogic Integration Javadoc.
To learn more about creating an initial context, see Class Environment in the Oracle WebLogic Integration Javadoc.
JpdProxyException
, which wraps checked exceptions thrown during construction of the proxy.To determine which client request methods are available for you to use via the JPD Proxy, review the source code for the business process. To do so, ensure that the business process (JPD) is open in the Oracle Workshop for WebLogic graphical design environment, identify the Client Request calls in the Design view, then open the Source view, where you can view the method names and signatures.
JPD Proxies cannot receive callbacks from business processes. See Limitation Using JPD Proxies for Business Processes That Include Client Callbacks.
Business processes can accept (as input) and return typed XML (XML Beans) and typed binary data (MFL). The JPD contract interface generated from such business process references these types. (For an example of an XML type referenced in a JPD contract, see the code listing in What is a JPD Proxy?)
Note that in our example Java client, in Listing 29-2, the following packages are imported to support the XML Bean types used in the PoProcess business process:
import requisitionpo.www.purchase.PurchaseDocument;
import requisitionpo.www.purchaserequestreq.PurchaseRequestReqDocument
You can use the JpdProxySession
interface to set and get the conversation ID used when a business process is invoked. To use the JpdProxySession
interface, clients can simply typecast proxies returned by JpdProxy.create()
to JpdProxySession
.
The dynamic proxy returned by JpdProxy.create()
implements the JpdProxySession
interface. The methods on the JpdProxySession
interface include:
String getConversationID()
void reset()
void setConversationID(String conversationID)
The conversation ID is initialized to null. If the conversation ID is null when a method on a business process is invoked through the JPD Proxy, a unique conversation ID is generated. This unique ID is maintained in the run-time state on the client side. In other words, the value is maintained for subsequent invocations, until the client specifies a new conversation ID or resets it to null.
The same JPD Proxy instance can be used to call methods on different instances of a business process. However, clients should take care to avoid making a call with the wrong conversation ID. Specifically, when a client application is finished invoking an instance of a business process through its JPD Proxy and wants to start a new conversation, it must either explicitly set the conversation ID for the second conversation or call JpdProxySession.reset()
, which causes the JPD Proxy to reset the conversation ID to null.
To learn more about the JpdProxySession interface, see Interface JpdProxySession in the Oracle WebLogic Integration Javadoc.
The following command line describes the options that you must set when you run the example Java client (startPoProcess
) shown in
Listing 29-2.
java -Dbea.home=C:\bea
startPoProcess
where -Dbea.home=
C:\bea
specifies the product installation location.
JPD Proxies cannot receive callbacks from business processes. Business processes that include client callbacks send those callbacks to the client that started the business process. If a client uses a JPD Proxy to start a business process that includes client callbacks, the business process fails at run time when it tries to send the callback to the client that started it (the JPD Proxy).
The example described in this section shows you how to add two-way SSL to a Java client. This section also describes the command-line options required to run the Java client so that the two-way SSL handshake can take place between the Java client and the SSL server. This section includes the following topics:
The following example demonstrates how to add two-way SSL to a Java client. The example code is explained in the text that follows the listing.
import weblogic.wli.jpdproxy.MyProcess;
import javax.naming.Context;
import javax.naming.NamingException;
import weblogic.jndi.Environment;
import com.bea.wli.bpm.proxy.JpdProxy;
import java.io.*;
import javax.naming.InitialContext;
public class startMyProcess
{
public static void main(String[] args)
{
try {
InputStream key = new FileInputStream("C:\\certcmds\\qa\\pki\\keys\\newParent.key");
InputStream cert = new FileInputStream("C:\\keystore\\newParentx509.cer");
final InputStream FStream[] = {key,cert};
MyProcess tm = (MyProcess)
JpdProxy.create(MyProcess.class,MyProcess.SERVICE_URI,
new JpdProxy.ContextHandler()
{
public Context getContext() throws NamingException
{
Environment env = new Environment();
//Use t3s – secure port for ssl
env.setProviderUrl("t3s://localhost:7002");
//Client Certificate and Private Key for that certificate.
env.setSSLClientCertificate(FStream);
env.setSSLClientKeyPassword("testing123");
return env.getInitialContext();
}
});
String str = tm.requestQuote();
System.out.println("Return String = " + str);
}
catch (Exception ex)
{
//Got an exception
System.out.println("Got Exception: " + ex);
ex.printStackTrace();
}
}
}
This example builds on the information provided in the previous section (
To Use a JPD Proxy From a Java Client) by demonstrating how to add two-way SSL to the Java client. The example code in
Listing 29-5 shows a Java client that uses a JPD Proxy to invoke a business process named MyProcess.java
.
The following items describe the lines of code used to set up the two-way SSL between the client and Oracle WebLogic Server:
import weblogic.wli.jpdproxy.MyProcess;
This client accesses the business process via proxy classes found in MyProcess.jar
, in the default package: weblogic.wli.jpdproxy
.
final InputStream FStream[] = {key,cert};
To pass the digital certificates to JNDI, an array of InputStreams
opened on files containing DER-encoded1 digital certificates is created. The first element in the array is a private key file; it is followed by the Java client’s digital certificate file, or files2. (The digital certificate file contains the public key for the Java client.)
Note: | If you have PEM-encoded data, you can wrap your InputStreams in PEMInputStream classes before passing them in. To do so, add the following lines of code after you create instances of the PEM-encoded key and certificates in your file: // wrap input streams if key/cert are in pem files The
weblogic.security.PEMInputStream class reads digital certificates stored in PEM files.The private key is the first input stream in the array; subsequent input streams in the array can be a single certificate (as in our example) or a chain of X.509 certificates. |
You must create a new Environment
object for each call to the getInitialContext()
method. Once you specify a User
object and security credentials, both the user and their associated credentials remain set in the Environment
object.
Environment
class creates a hash table to store these parameters:env.setProviderURL
—The client calls this method to specify the URL of the Oracle WebLogic Server instance acting as the SSL server. In this example, the URL specifies the t3s protocol which is a Oracle WebLogic Server proprietary protocol built on the SSL protocol.Note: | In addition to the t3 and t3s protocols, Oracle WebLogic Server clients can use the RMI over IIOP protocol. To learn about using RMI over IIOP, see Programming Oracle WebLogic RMI over IIOP in the Oracle WebLogic Server documentation. |
return env.getInitialContext();
When the JNDI getInitialContext()
method is called, the Java client and Oracle WebLogic Server execute mutual authentication. An exception is thrown if the digital certificates cannot be validated or if the Java client’s digital certificate cannot be authenticated in the default (active) security realm. The authenticated user object is stored on the Java client’s server thread and is used for checking the permissions governing the Java client’s access to any protected Oracle WebLogic resources.
The following command line describes the options that you must set when you run the example Java client (startMyProcess
) shown in
Listing 29-5. Setting these options ensures that the two-way SSL handshake can take place between the Java client and Oracle WebLogic Server.
java -Dbea.home=C:\bea
-Djava.protocol.handler.pkgs=com.certicom.net.ssl
-Dweblogic.security.SSL.ignoreHostnameVerification=true
-Dweblogic.security.TrustKeyStore=CustomTrust
-Dweblogic.security.CustomTrustKeyStoreFileName=c:\keystore\trustCA.jks
-Dweblogic.security.CustomTrustKeyStoreType=jks
startMyProcess
The command-line options you use depend on the type of trust set up on Oracle WebLogic Server. In this example, Oracle WebLogic Server was set up with a Custom Trust. (Other options include the Oracle WebLogic Server Demo Trust and Java Standard Trust.)
In the preceding command line:
-Dbea.home=C:\bea
—Specifies the product installation location.-Djava.protocol.handler.pkgs
—Specifies the protocol handler.Note: | SSL Client License Requirement—Any stand-alone Java client that uses WebLogic SSL classes (weblogic.security.SSL ) to invoke an Enterprise Java Bean (EJB) must use the BEA license file. When you run your client application, you must set the -Dbea.home and the -Djava.protocol.handler.pkgs system properties on the command line: |
-Dweblogic.security.SSL.ignoreHostnameVerification
—Disables host-name verification. Specifically, the client does not verify that the host name, which the SSL server returns in its digital certificate, matches the host name of the URL used to connect to the SSL server. We recommend that you enable hostname verification when you run your application in production.-Dweblogic.security.TrustKeyStore
—Specifies the keystore used by the the server instance to which you want to connect. In this example, the server is using a custom keystore: CustomTrust.-Dweblogic.security.CustomTrustKeyStoreFileName
—Specifies the fully qualified path to the trust keystore.-Dweblogic.security.CustomTrustKeyStoreType
—This optional command-line argument specifies the type of the keystore. The value defaults to the keystore type specified in the JDK’s java.security
file. Generally, the value is jks
.Note: | If the custom keystore is protected by a password, include the following: -Dweblogic.security.CustomTrustKeystorePassPhrase= password . |
Our example trusts the CA certificates in a custom keystore. The command-line options you use depend on the type of trust set up on Oracle WebLogic Server. For instance:
SDK_HOME\jre\lib\security\cacerts
), you do not need to specify command-line arguments, unless the keystore is protected by a password. If the Java Standard Trust keystore is protected by a password, use the following command-line argument:-Dweblogic.security.JavaStandardTrustKeystorePassPhrase=password
BEA_HOME\wlserver_10.3\server\lib\DemoTrust.jks
), include the following argument: -Dweblogic.security.TrustKeyStore=DemoTrust
This argument is required if the server instance to which you want to connect is using the demonstration identity and certificates. If the Java Standard Trust keystore is protected by a password, include the following command-line argument:
-Dweblogic.security.JavaStandardTrustKeystorePassPhrase=password
To learn more about using SSL authentication in Java clients, see the Oracle WebLogic Server documentation:
Weblogic JNDI Environment Class
weblogic.Admin Command-Line Reference
<%@ page import="com.bea.wli.bpm.proxy.JpdProxy"%>
<%@ page import="com.bea.wli.bpm.proxy.JpdProxySession"%>
To learn about using the JpdProxySession
interface, see
To Import the Proxy Classes.
Using the same example as we used in How Do I: Use a JPD Proxy From a Java Client?, the code should resemble the following code:
try
{
PoProcess p = (PoProcess)
JpdProxy.create(
PoProcess.class,
PoProcess.SERVICE_URI,
new JpdProxy.ContextHandler()
{
public Context getContext() throws NamingException
{
Environment env = new Environment();
env.setProviderUrl("t3://localhost:7001");
env.setSecurityPrincipal("weblogic");
env.setSecurityCredentials("weblogic");
return env.getInitialContext();
}
});
PoDocument document = PoDocument.Factory.newInstance();
Po po = document.addNewPo();
po.setSku("abc");
PoReferenceDocument ref = p.processPO(document);
p.done();
}
catch (Exception e) { ... }
}
%>
</html>
Note: | To learn about the signatures of the JpdProxy.create() class, see
To Use the Proxy Factory (JpdProxy.create()) Method. |
You can use a JPD Proxy to invoke a business process from an EJB in the same way as you use a JPD Proxy from any Java file. To learn how, see How Do I: Use a JPD Proxy From a Java Client?
To learn about developing EJBs, see Programming WebLogic Enterprise JavaBeans.