Para cualquier proceso BPEL que contenga fragmentos de código Java, en esta sección se describe cómo llevar a cabo la migración de la antigua API de fragmentos de código Java a la nueva API de fragmentos de código Java en que los datos que fluyen por la aplicación se almacenan como objetos de datos de servicio (SDO) de Eclipse.
Consulte la sección "Migrar desde las llamadas API de WSIFMessage a las API de SDO" para conocer los pasos de migración específicos de la transición de WSIFMessage a SDO a realizar.
Siempre que es posible el asistente de migración migra automáticamente los fragmentos de código, pero hay fragmentos de código que el asistente de migración no puede migrar por completo. Por consiguiente, es preciso realizar una serie de pasos manuales adicionales para completar la migración. Consulte el tema Limitaciones para conocer más detalles acerca de los tipos de fragmentos de código Java que deben migrarse manualmente. Siempre que se encuentre uno de estos fragmentos de código, el asistente Migración explicará por qué no puede migrarse automáticamente y emitirá un aviso o un mensaje de error.
Cambio | Solución |
---|---|
Las clases de envoltura basadas en WSIFMessage ya no se generan para tipos de mensaje WSDL ni tampoco las clases de ayuda de bean Java para los tipos de esquema complejos. | Es posible acceder a las variables de BPEL directamente por nombre. Tenga
en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo
componente, ahora estas variables representarán directamente el componente en lugar de
tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán
una envoltura DataObject alrededor de los componentes (donde la envoltura en
WebSphere
Application Developer Integration Edition era un WSIFMessage.) Puesto que las variables BPEL pueden utilizarse directamente en fragmentos de código de 6.0, son menos necesarias de lo que lo eran en 5.1. Los métodos de obtención rigurosos para las variables BPEL inicializaban implícitamente el objeto de envoltura WSIFMessage alrededor de los componentes de mensaje. No hay ningún objeto de ‘envoltura’ para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente: en este caso, las variables de BPEL representan directamente el componente. (en el caso en que el único componente sea un tipo simple XSD, la variable BPEL estará representada como el tipo de envoltura de objeto Java como por ejemplo java.lang.String, java.lang.Integer, etc.) Las variables BPEL con definiciones de mensaje WSDL de varios componentes se tratan de forma distinta: todavía hay una envoltura alrededor de los componentes y esta envoltura DataObject debe inicializarse explícitamente en el fragmento de código Java 6.0 si es que no la ha establecido una operación anterior. Si las variables locales de los fragmentos de código 5.1 tenían el mismo nombre que la variable BPEL, puede haber conflictos, de modo que intente remediar la situación si es posible. |
Los objetos WSIFMessage ya no se utilizan para representar variables BPEL. | Si las clases Java personalizadas invocadas desde los fragmentos de código Java tienen un parámetro WSIFMessage, será necesario migrarlo de forma que acepte/devuelva un DataObject. |
Los métodos de obtención rigurosos para las variables BPEL ya no están disponibles. | Es posible acceder a las variables directamente por nombre. Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, ahora directamente representará el componente en lugar de tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán una envoltura DataObject alrededor de los componentes (donde la envoltura en WebSphere Application Developer Integration Edition era un WSIFMessage.) |
Los métodos de establecimiento rigurosos para las variables BPEL ya no están disponibles. | Es posible acceder a las variables directamente por nombre. Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, ahora estas variables representarán directamente el componente en lugar de tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán una envoltura DataObject alrededor de los componentes (donde la envoltura en WebSphere Application Developer Integration Edition era un WSIFMessage.) |
Los métodos de obtención permisivos para las variables de BPEL que devuelven un WSIFMessage ya no están disponibles. | Es posible acceder a las variables directamente por nombre. Tenga
en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo
componente, ahora estas variables representarán directamente el componente en lugar de
tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán
una envoltura DataObject alrededor de los componentes (donde la envoltura en
WebSphere
Application Developer Integration Edition era un WSIFMessage.) Tenga en cuenta que había
dos variaciones del método getVariableAsWSIFMessage:
getVariableAsWSIFMessage(String variableName)getVariableAsWSIFMessage(String variableName, boolean forUpdate) Para una actividad de fragmento de código
Java,
el acceso por omisión es de lectura-escritura.
Puede cambiarlo a sólo lectura especificando
@bpe.readOnlyVariables con la lista de nombres de las variables en
un comentario en el fragmento de código. Por ejemplo, puede establecer las variables B y D a sólo
lectura del siguiente modo:
variableB.setString("/x/y/z", variableA.getString("/a/b/c")); // @bpe.readOnlyVariables names="variableA" variableD.setInt("/x/y/z", variableC.getInt("/a/b/c")); // @bpe.readOnlyVariables names="variableC" Además, si tiene un fragmento de código Java en una condición, las variables son de sólo lectura por omisión, pero puede cambiarlas a lectura-escritura especificando @bpe.readWriteVariables... |
Los métodos de establecimiento permisivos para las variables BPEL ya no están disponibles. | Es posible acceder a las variables directamente por nombre. Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, ahora estas variables representarán directamente el componente en lugar de tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán una envoltura DataObject alrededor de los componentes (donde la envoltura en WebSphere Application Developer Integration Edition era un WSIFMessage.) |
Los métodos de obtención permisivos para los componentes de mensaje de variables BPEL no son adecuados para los mensajes de un solo componente y se han cambiado por mensajes de varios componentes. | Migre al método de obtención permisivos para las
propiedades de las variables BPEL (de DataObject). Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, la variable BPEL representa directamente el componente y debería accederse directamente a la variable sin utilizar un método de obtención. Había dos variaciones del método getVariablePartAsObject:
getVariablePartAsObject(String variableName, String partName) getVariablePartAsObject(String variableName, String partName,boolean forUpdate) Para los mensajes de varios componentes, este método proporciona funcionalidad equivalente en 6.0:
getVariableProperty(String variableName, QName propertyName); En 6.0 no existe el concepto de utilización de una variable para el acceso solo de lectura (lo que sí existía en 5.1 para el primer método que figura más arriba, así como para el segundo método con forUpdate=’false’.) La variable se utiliza directamente en el fragmento de código 6.0 y siempre puede actualizarse. |
Los métodos de establecimiento permisivos para los componentes de mensaje de variables BPEL no son adecuados para los mensajes de un solo componente y se han cambiado por mensajes de varios componentes. | Migre al método de establecimiento permisivo para las
propiedades de las variables BPEL (de DataObject). Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, la variable BPEL representa directamente el componente y debería accederse directamente a la variable sin utilizar un método de establecimiento. Es necesario migrar las llamadas al método siguiente:
setVariableObjectPart(String variableName, String partName, Object data) Para los mensajes de varios componentes, este método proporciona funcionalidad equivalente en 6.0:
setVariableProperty(String variableName, QName propertyName,Serializable value); |
Los métodos de obtención rigurosos para los enlaces de socio de BPEL ya no están disponibles. | Migre a los métodos de obtención permisivos para enlaces de socio de BPEL. |
Los métodos de establecimiento rigurosos para los enlaces de socio de BPEL ya no están disponibles. | Migre a los métodos de establecimiento permisivos para enlaces de socio de BPEL. |
Los métodos de obtención rigurosos para los conjuntos de correlación de BPEL ya no están disponibles. |
|
Se necesita un parámetro adicional para los métodos de obtención con tipo difuminado para las propiedades personalizadas de actividad BPEL. |
|
Se necesita un parámetro adicional para los métodos de establecimiento con tipo difuminado para las propiedades personalizadas de actividad BPEL. |
|
El método raiseFault(QName faultQName, Serializable message) ya no existe. | Migre raiseFault(QName faultQName, String variableName) cuando sea posible, de lo contrario migre al método raiseFault(QName faultQName) o cree una variable BPEL nueva para el objeto serializable. |