![]() ![]() ![]() ![]() ![]() ![]() |
This section describes known limitations in the BEA WebLogic Integration 9.2 release software. The known limitations are grouped by the following topics:
If you installed WebLogic Integration and opted to apply patches after successful completion of the installation, the installer automatically applies patches to WebLogic Server, Workshop for WebLogic Platform, and WebLogic Portal.
The installer does not check whether WebLogic Portal or Workshop for WebLogic Platform are installed or not. So, patches to these two products are applied even if they are not installed
|
|||
After application source upgrade, MFL Transformation failed with XQuery Exception (XQRLUserException).
Unlike in 8.x, the 9.2 MFL-derived XMLBeans belong to a namespace. So, the upgraded XQuery transformations that use MFL-derived XMLBeans as output types must be manually updated to yield XML with elements in the appropriate namespace. The namespace used is determined by the path of the MFL file, relative to the schema source directory.
|
|||
The user portal displays default values that are actually not in the database. If you accept these values, they are inserted into the database.
|
|||
When you create a Platform-like by adding wlp.jar template onto a WLI domain, with express mode or user explicitly selecting run DB script, loadDB fails when extending wlp.jar and the domain does not start.
Workaround: Using the Configuration Wizard tool, create a Platform-like domain by adding WebLogic Integration templates to a WebLogic Portal domain, or by selecting the WebLogic Portal and WebLogic Integration check-boxes.
When you create a Platform-like by adding the WebLogic Portal component onto a WebLogic Integration domain, with express mode or user explicitly selecting run DB script, loadDB fails when extending wlp.jar and the domain does not start.
When you create a WebLogic Portal domain by extending workshop_wl.jar, p13n.jar and wlp.jar templates, one template at a time, with express mode or user explicitly selecting run DB script, loadDB fails when extending wlp.jar and the domain does not start.
When you create a WebLogic Portal domain by extending workshop_wl.jar, p13n.jar and wlp.jar templates, one template at a time, with loadDB() invoked each time extending a template, loadDB fails when extending wlp.jar and the domain does not start.
Workaround: Extend the required templates together and invoke loadDB() explicitly in the WLST script.
|
|||
WebLogic Integration 9.x domains take longer to start up when compared with WebLogic Integration 8.x domains.
The problem has been mitigated by removing extra backward compatibility resources from newly created WebLogic Integration domains. Newly created domains will not deploy backward compatibility resources (applications, etc.) and will thus boot more rapidly than if those resources were present in the domain.
|
|||
If your application enables message buffering on controls or web services using the annotations com.bea.control.annotations.MessageBuffer or weblogic.jws.MessageBuffer, the following error is displayed when you try to deploy it on a cluster:
"While attempting to create destination MSG_BUFFER_QUEUE in module <name_of_your_ear>!WlwRuntimeAppScopedJMS the JMSServer of name <name_of_your_cluster> could not be found".
|
|||
Any new task plan, by default does not have a create policy for any user: this has to be done explicitly through the worklist console. If this policy is not configured, then the JPDs’ that create tasks and are initiated through the JPD test console fail: This is because the JPD test console invokes the JPDs’ without any authentication and the JPD is run without any principal, thus as 'Anonymous'.
|
|||
While working on the Worklist Console, you may encounter the java.lang.OutOfMemoryError: PermGen space memory error.
|
|||
Unauthorized users (users who do not have Administration/Update/Query rights, or claimant, assignee rights) can see the built-in and user-defined properties of a task. This can happen when a control callback or TaskEventListener delivers a TaskEvent containing this information.
Workaround: Asynchronous events still have user properties as ChangedProperty instances (each containing a PropertyInstance with a name, type, and so on.) on them, but the property values equals to null. For system properties, they receive a ChangedProperty instance with a name, but the value is equal to null.
|
|||
Do not use the WebLogic Integration Administration Console to access your business process to secure SOAP-HTTP access to your business process if you have already secured your business process using the security-constraint element in the web.xml deployment descriptor and the @common:security annotation. You will receive a security violation at run time. For more information, see the following:
|
|||
To avoid a possible problem in subsequent archiving, if both of the following conditions are met, the result of a trackdata() call will not be recorded in the WebLogic Integration process events table.
The transaction that calls JpdContext.trackData(XmlObject value) or JpdContext.trackData(RawData value) is rolled back.
|
|||
|
Attempting to load data in the TPM repository with the Bulk Loader configured to use an XA database driver fails with the following error: No suitable driver.
Workaround: Configure the Bulk Loader to use a non-XA driver, or load the data interactively using the WebLogic Integration Administration Console.
For information about how to configure the Bulk Loader, see “Configuring the Bulk Loader Configuration File” in
Using the Trading Partner Bulk Loader in Managing WebLogic Integration Solutions at the following URL:
|
|
Workaround: If you need the DOCTYPE element in further processing, add it back into your message by using the obj.documentProperties().setDoctypeSystemId in a Perform node following the transformation. An example of this is shown in the “Walkthrough of the Failure Notifier Business Process” section of the “Step 2: Open the PIP0A1: Notification of Failure Example” example under the “Tutorial Steps” heading of the
Tutorial: Building RosettaNet Solutions available at the following URL:
|
|
The two default trading partners that are created when you create a new WebLogic Integration domain have new default trading partner ids, as shown in Table 2-1.
|
|
In WebLogic Integration, you use Trading Partner Integration controls to send messages from the initiator business process to the participant business process. However, in the participant business process it is recommended that you use Client Response nodes to handle outgoing business messages to the initiator.
If you use controls in a participant business process, you may lose the message response signals, such as acknowledgments and error messages. If you need to use a control to send messages instead of using the recommended design pattern, place the control in a subprocess and invoke the subprocess from the participant process.
|
After application source upgrade, MFL Transformation failed with XQuery Exception (XQRLUserException).
In 9.2, MFL-derived XMLBeans belong to a namespace. In 8.x, XQuery transformations that use MFL-derived XMLBeans as output types must be manually updated to yield XML with elements in the appropriate namespace. The namespace used is determined by the path of the MFL file, relative to the schema source directory.
|
|
Workaround: The upgrade does not set the security policy when the default authenticator is used. If you use an authorization provider other than the default LDAP provider, you need to either check or set this security policy.
After you upgrade a WebLogic Integration 8.1 domain, you must set the security policies on the Compatibility 8.1.x Task Plan and allow the 'Anonymous' role in the Create Policy. Use the Worklist Administration Console (the default authorization provider) to set the Create Policy for the Compatibility 8.1.x task plan. If you are using a third-party authorizer, use the related third-party client tools to set the policy.
|
|
Inlined XQuery expressions that occur within process annotations are not updated after selecting the "Upgrade XQ2002 to XQ2004" option.
|
|
A process application is created with JWS and a MessageBuffer annotation. The application is published from Workshop and tested. A few changes are made to the web application without republishing it from Workshop. Invoking either the JWS or a JPD from the test console results in an "Unable to deploy EJB..." error
|
|
Workshop Web Service Control generated in 8.1 SP4 with types selected to Java for a complex type array with rpc/encoded mapped the complex type array to anyType[ ] instead of the concrete type array. For example:
<schema targetNamespace="urn:serviciosAdminNE" xmlns="http://www.w3.org/2001/XMLSchema";;>
<import namespace="http://schemas.xmlsoap.org/soap/encoding/";;/> <complexType name="Aplicacion"> <sequence> <element name="certificado" type="xsd:base64Binary"/> <element name="descripcion" nillable="true" type="xsd:string"/> <element name="idAplicacion" nillable="true" type="xsd:string"/> <element name="nombre" nillable="true" type="xsd:string"/> <element name="organismo" nillable="true" type="xsd:string"/> </sequence> </complexType> <complexType name="AplicacionArray"> <sequence> <element name="abonadoArray" nillable="true" type="impl:ArrayOf_tns1_Aplicacion"/> <element name="aplicacionArray" nillable="true" type="impl:ArrayOf_tns1_Aplicacion"/> </sequence> </complexType> </schema> <schema targetNamespace="http://notanot/jboss-net/services/ServicioWEBAdminNE";; xmlns="http://www.w3.org/2001/XMLSchema";;> <import namespace="http://schemas.xmlsoap.org/soap/encoding/";;/> <complexType name="ArrayOf_tns1_Aplicacion"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="tns1:Aplicacion[]"/> </restriction> |
|
public static class AplicacionArray implements java.io.Serializable
{ public anyType[] abonadoArray; public anyType[] aplicacionArray; } public static class anyType implements java.io.Serializable { private static final long serialVersionUID = 1L; public XmlObject[] t; }
anyType[] is not supported by 9.2 Workshop Web Service Control. Therefore, the above Service Control after upgrade will cause errors during deployment or application archive.
Workaround: After upgrade change the types in the service control to point to the concrete type. For example:
public static class Aplicacion implements java.io.Serializable
{ public byte[] certificado; public java.lang.String descripcion; public java.lang.String idAplica ion; public java.lang.String nombre; public java.lang.String organismo; } public static class AplicacionArray implements java.io.Serializable { public Aplicacion[] abonadoArray; public Aplicacion[] aplicacionArray; } |
|
ebXML application using ebXMLControl within java custom control results in a Null Pointer Exception when ControlHandle.sendEvent is not used.
Workaround: Read the note and example to JPD and Control Callback section of the WebLogic Integration 9.2 Upgrade Guide. The information is available at
http://download.oracle.com/docs/cd/E13214_01/wli/docs92/upgrade/component.html.
|
|
Upgrading an 8.x application that contains Schemas and adding a prefix in the Workshop for Weblogic Platform Upgrade Wizard.
If you add a prefix to an 8.x application with Schemas from the Upgrade Wizard, it will result in an error. This is because the upgrade utility looks for the Schemas.jar file, with the specified prefix, in the 8.x application directory. No such file exists as only the Schemas.jar file is present in the 8.x application directory.
|
|
Error upgrading B2B application as a result of incompatible package reference in a JPD and the Control file.
|
|
There are two known issues in wftracking/M2_ArchHelloAsync.java file and Process_Tracking_Binary.java. Remove throws Exception from helloDelay_onTimeout methods.
|
|
Workshop for WebLogic Platform 9.2 Web Service Control generation is not supported from an 8.x WSDL containing callbacks.
|
|
Workshop for WebLogic Platform 9.2 Web Service Controls do not support receiving 8.x-style callback messages from an 8.x style end point service.
If your 8.x application contains the use case of a JWS (caller) using the Workshop Web Service Control (caller) to invoke and receive a callback from another JPD (callee), it will not function correctly after upgrade.
|
|
Workshop for WebLogic Platform 9.2 Web Service Controls do not support receiving 8.x-style callback messages from an 8.x style end point service.
If your 8.x application contains the use case of a JPD (caller) using the Workshop Web Service Control (caller) to invoke and receive a callback from another JPD (callee), it will not function correctly after upgrade.
Workaround: It is recommended that you upgrade both the callee (JPD) and the caller (JPD and Workshop Web Service and execute the following steps:
|
|
![]() ![]() ![]() |