Prácticas para promover y desplegar servicios de un ambiente a otro construidos con Oracle SOA Suite

Por Rolando Carrasco
Publicado en febrero 2013

Oracle Soa Suite Services Composition

Este es el artículo completo relacionado a la promoción y despliegue de Servicios entre diferentes ambientes. Servicios construidos con la plataforma Oracle SOA Suite 11g.

De esto escribí un poco en mi blog: oracleradio.blogspot.com, pero en definitiva aquí es dónde encontrarás una descripción detallada de cómo hacerlo.

Una situación que siempre es clave en el control y gobernabilidad del Desarrollo que se hace alrededor de Servicios, es su promoción entre ambiente y ambiente.

En años pasados (2006-2008), en la SOA Suite 10g, tenía su reto hacer ésto, pues tocaba escribir tus propios scripts de ANT. Si bien era lograble, no era tan simple como ahora en la versión 11g, y asumo se mejorará todavía más en siguientes versiones.

En principio, lo más simple que puede llegar a suceder es tener Compuestos que dependan de:

  • Adaptadores hacia Bases de Datos: dónde el nombre del Adapter entre un ambiente y otro sea diferente
  • Web Services HTTP/SOAP: dónde claramente el nombre del host será diferente, quizás también el puerto, y en algunos casos el contexto
  • Adaptadores hacia Servidores FTP: al igual que en el caso de Base de Datos, el nombre del adapter seguramente será diferente entre ambientes
  • Llamadas a compuestos de la misma infraestructura: aquí es similar al punto 2 de esta lista
  • Llamadas a Servicios expuestos en Service Bus: en realidad es lo equivalente al punto 2 en caso de que sea por HTTP/SOAP
  • Adaptadores hacia colas de Mensajería (JMS/MQ/AQ): Es muy equivalente a los de Base de datos, en tanto que lo que puede cambiar es el nombre del Adapter entre ambiente y ambiente

Desde el punto de vista de Desarrollo, estas dependencias se ubican y se tiene cierto control sobre a qué sistema te estás conectando, pero para el rol que realiza los despliegues hacia Producción, eC_BPEL_NOTIFICA_ERRORES_APPA#wsdl.endpoint(c_bpel_notifica_errores_appa_client_epsto no es necesariamente cierto. Además que en este tipo de ambiente, regularmente existe una persona dedicada al despliegue de componentes hacia Producción.

Este rol, debe recibir el paquete a desplegar y tener una forma práctica de realizarlo sin necesidad de modificar el fuente del proyecto. Simplemente debería de ser capaz de tomar el paquete e indicar hacia qué ambiente quiere promoverlo. Esto se puede hacer de varias maneras:

1. Desde el propio Enterprise Manager del ambiente en cuestión
2. Utilizando Scripts de ANT (regularmente así se hace)
3. Utilizando el JDeveloper. Esto no es muy recomendado, pues implica abrir el fuente, y cualquier cambio que por equivocación se haga, alteraría la consistencia del componente a desplegar.

Lo que es una constante en cualquiera de estos escenarios es la utilización de los Configuration Plans, que son archivos de configuración en dónde se pueden establecer los cambios que se requieren aplicar para que el despliegue apunte hacia los ambientes indicados. Estos Config Plans sirven para indicar los cambios de nombres, ubicaciones, urls, puertos, etc, que se necesitan para diferenciar entre un ambiente y otro.

Para generarlo, basta con que des click derecho sobre el composite.xml y escojas la opción de: Generate Config Plan.

Generate Config Plan
Ilustración 1 - Generación de Config Plan

Esto generará un archivo XML, similar al siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<SOAConfigPlan xmlns:jca="http://platform.integration.oracle/blocks/adapter/fw/metadata" 
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" 
xmlns:edl="http://schemas.oracle.com/events/edl" 
xmlns="http://schemas.oracle.com/soa/configplan">

  
   <composite name="TestComposite">
 
 <!--Add search and replace rules for the import section of a composite
	Example:
	<searchReplace>
		<search>http://my-dev-server</search>
		<replace>http://my-test-server</replace>
	<searchReplace>
	<searchReplace>
		<search>8888</search>
		<replace>8889</replace>
	<searchReplace>-->
      <import>
         <searchReplace>
            <search/>
            <replace/>
         </searchReplace>
      </import>
      <service name="testcomposite_client_ep">
         <binding type="ws">
            <attribute name="port">
               <replace>http://xmlns.oracle.com/OTNArticle/TestComposite/
TestComposite#wsdl.endpoint(testcomposite_client_ep/TestComposite_pt)"/replace>
            </attribute>
         </binding>
         <callback>
            <binding type="ws">
               <attribute name="port">
                  <replace>http://xmlns.oracle.com/OTNArticle/TestComposite/
TestComposite#wsdl.endpoint(testcomposite_client_ep/TestCompositeCallback_pt)</replace>
               </attribute>
            </binding>
         </callback>
      </service>
      <!--Add search and replace rules for the component properties
	For components and service/reference bindings, you can add policy references.
	Example:
	<component name="*">
		<wsp:PolicyReference orawsp:category="management" orawsp:status="enabled" 
URI="oracle/log_policy"/>
	</component>-->
   </composite>
   <!--To configure monitor.config: 
	<property name="enabled"><replace>true</replace></property>
	<property name="dataObjectsFolder"><searchReplace><search>mydev</search>
<replace>myproduction</replace></searchReplace></property>
	
	sample properties to configure for adapter: 
	<jca:property name="QueueName"><replace>medmq1</replace></jca:property>
	
	To add search and replace rules for wsdls, xsd and jca files
	Example:
	<searchReplace>
		<search>http://my-dev-server</search>
		<replace>http://my-test-server</replace>
	<searchReplace>
	<searchReplace>
		<search>8888</search>
		<replace>8889</replace>
	<searchReplace>
	-->
   <wsdlAndSchema name="TestComposite.wsdl|xsd/TestComposite.xsd">
      <searchReplace>
         <search/>
         <replace/>
      </searchReplace>
   </wsdlAndSchema>
</SOAConfigPlan>

Las secciones que se pueden identificar en el Config Plan, son:

      <!--Add search and replace rules for the import section of a composite 
    Example: 
    <searchReplace> 
        <search>http://my-dev-server</search> 
        <replace>http://my-test-server</replace>
    <searchReplace>
    <searchReplace> 
        <search>8888</search> 
        <replace>8889</replace> 
    <searchReplace>-->

Esta es la parte de hasta arriba del Configuration Plan. Y como lo indica la documentación, está enfocado a la substitución de datos en la Sección de Import del Compuesto en cuestión.

Es decir, cualquier cosa que esté en el Import Section del composite.xml es susceptible a ser cambiada en esta sección. Por ejemplo:

<composite name="OTNArticle"
           revision="1.0"
           label="2012-05-16_17-00-31_215"
           mode="active"
           state="on"
           xmlns="http://xmlns.oracle.com/sca/1.0"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
           xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
           xmlns:ui="http://xmlns.oracle.com/soa/designer/">
  <import namespace="http://xmlns.oracle.com/pcbpel/adapter/file/LecturaArchivo/BPEL_LecturaArchivo/
Lectura" location="Lectura.wsdl" importType="wsdl"/>
  <import namespace="http://xmlns.oracle.com/LecturaArchivo/BPEL_Inserta_datos"
          location="http://rcarrasco-mx:8001/soa-infra/services/interfaces/
BPEL_Inserta_datos/BPEL_datos.wsdl"
          
          
          importType="wsdl"/>

En este ejemplo se tiene un par de imports , en dónde hay datos como el location (marcado con rojo) que pudieran ser cambiados entre ambientes. De manera que si quisiéramos cambiar la ubicación, puerto de esta entrada, la primera sección del Plan, luciría de la siguiente manera:

        <searchReplace> 
        <search> rcarrasco-mx </search> 
        <replace>ambiente-prod</replace> 
    <searchReplace> 
    <searchReplace> 
        <search>8001</search> 
        <replace>14000</replace> 
    <searchReplace>



Así estamos intercambiando ambos valores de la ubicación y puerto.

Posteriormente, vienen las entradas de cada referencia que se tenga en el Compuesto: Servicios, Adapters, etc.

Cada una de las referencias, tiene sus propias características que pueden ser intercambiadas, por ejemplo, en el caso de un WS tradicional, en la entrada siguiente , marcamos con rojo los atributos que se intercambiarían al utilizar este Config Plan:

<reference name="AltaCliente"> 
   <!--Add search and replace rules for the binding properties--> 
   <binding type="ws"> 
      <attribute name="port"> 
         <replace>http://xmlns.oracle.com/SOA_ejemplo/ejemplo_BPEL/
ejemplo_BPEL#wsdl.endpoint(ejemplo_bpel_client_ep/ejemplo_BPEL_pt)</replace> 
      </attribute> 
      <attribute name="location"> 
         <searchReplace> 
            <search>maquinaTest</search> 
            <replace>maquinaProd</replace> 
         </searchReplace> 
         <searchReplace> 
            <search>7777</search> 
            <replace>80</replace> 
         </searchReplace> 
      </attribute> 
      <property name="weblogic.wsee.wsat.transaction.flowOption"> 
         <replace>WSDLDriven</replace> 
      </property> 
      <property name="weblogic.wsee.wsat.transaction.flowOption"> 
         <replace>WSDLDriven</replace> 
      </property> 
      <property name="weblogic.wsee.wsat.transaction.flowOption"> 
         <replace>WSDLDriven</replace> 
      </property> 
   </binding> 
   <callback> 
      <binding type="ws"> 
         <attribute name="port"> 
            <replace>http://xmlns.oracle.com/SOA_ejemplo/ejemplo_BPEL_/
ejemplo_BPEL_APPA#wsdl.endpoint(ejemplo_bpel_client_ep/ejemplo_BPEL_Callback_pt)</replace> 
         </attribute> 
      </binding> 
   </callback> 
</reference>

Aquí hay que poner cierta atención, pues por default el Config Plan es generado de la siguiente manera:

      <reference name="VerificaTransactionImporj">
         <!--Add search and replace rules for the binding properties-->
         <binding type="ws">
           <attribute name="port">
               <replace>http://xmlns.oracle.com/SOA_INTERFACES_FII_jws/REPORTA_ERRORE/
BPEL_NOTIFICA_ERRORES#wsdl.endpoint(bpel_notifica_errore_client_ep/BPEL_NOTIFICA_ERRORES_pt)</replace>
            </attribute>
            <attribute name="location">
               <replace>http://test.com:8888/soa-infra/services/interfaces/BPEL_REPORTA_ERRORES/
bpel_errores_client_ep?WSDL</replace>
            </attribute>
            <property name="weblogic.wsee.wsat.transaction.flowOption">
               <replace>WSDLDriven</replace>
            </property>
         </binding>
         <callback>
            <binding type="ws">
               <attribute name="port">
                  <replace>http://xmlns.oracle.com/SOA_C_INTERFACES_FII_jws/
C_BPEL_SUELDOS_SALARIOS_REPORTA_ERRORES_APPA/
C_BPEL_NOTIFICA_ERRORES_APPA#wsdl.endpoint(c_bpel_notifica_errores_appa_client_ep/
C_BPEL_NOTIFICA_ERRORES_APPACallback_pt)</replace>
               </attribute>
            </binding>
         </callback>
      </reference>


Lo que está resaltado en rojo, es como el Config Plan genera la entrada, pero se debe cambiar a cómo se describió en párrafos pasados.

Se puede ver cómo en el atributo Location se hace el intercambio hacia la máquina de Producción.

Si estuviéramos usando algún Adaptador, por ejemplo de Base de Datos, la entrada en el Plan luciría de la siguiente manera:

<reference name="insertaCuenta">
         <property name="jca.retry.count">
            <replace>1</replace>
         </property>
         <property name="jca.retry.interval">
            <replace>60</replace>
         </property>
         <property name="jca.retry.backoff">
            <replace>1</replace>
         </property>
         <binding type="jca"/>
      </reference>

Este bloque se generaría de manera automática en el Config Plan, identificando las Propiedades utilizadas en el Adaptador. En este caso, se podrían configurar la cantidad de reintentos, los intervalos en los cuales se reintenta, etc. Esto es importante, pues no necesariamente estos parámetros son iguales en TEST que en PROD. Si bien el nombre del adapter no se cambia en esta sección, es importante tomarla en cuenta.

Finalmente, en la parte final del Plan, se encuentra una sección dónde se puede intercambiar cualquier valor que se encuentre en los archivos listados. Esto es en wsdls, xsds, etc:

<wsdlAndSchema name="ejemploSvc1.wsdl|ejemploSvc1_db.jca|ejemploSvc2.wsdl|ejemploSvc2_db.jca|
BPEL_ejemplo_SEND_EMAIL.wsdl|BPEL_ejemplo_SEND_EMAIL.xsd|bpel_ejemplo_send_email_client_ep.wsdl|
ejemploSvc3.wsdl|ejemploSvc3PRJ_TASK.wsdl|ejemploSvc3PRJ_TASK_db.jca|ejemploSvc3_db.jca|
ejemploSvc4_interface_rejections.wsdl|ejemploSvc4_interface_rejections_db.jca|
ejemploSvc4_invoices_interface_attribute15_db.jca|ejemploSvc4_invoice_lines_interface.wsdl|
ejemploSvc4_invoice_lines_interface_db.jca|Delete_At15_db.jca|DELETE_AtQ_db.jca|
DELETE_ATT.wsdl|DELETE_ATT_db.jca|deploy/sca_COMPUESTO_EJEMPLO_rev1.5/ejemploSvc1.wsdl|deploy/
sca_COMPUESTO_EJEMPLO_rev1.5/ejemploSvc1_db.jca|deploy/sca_COMPUESTO_EJEMPLO_rev1.5/ejemploSvc2.wsdl||
xsd/ejemplo_BPEL_LECTURA_ARCHIVO_AP.xsd|xsd/COMPUESTO_EJEMPLO.xsd|xsd/ejemploSvc3.xsd|xsd/
ejemploSvc3PRJ_TASK.xsd|xsd/DATOS_ENTRADA.xsd|xsd/DATOS_ENTRADA_PSFT_AP.xsd|
xsd/ejemploSvc4_interface_rejections.xsd|xsd/ejemploSvc4_invoices_interface_attribute15.xsd|
xsd/ejemploSvc4_invoice_lines_interface.xsd|xsd/Delete_At15.xsd|xsd/DELETE_AtQ.xsd|xsd/DELETE_ATT.xsd|
xsd/insertaCabecera_AP_table.xsd|xsd/insertaLinea_table.xsd|xsd/inserta_Datos_Reporte_table.xsd|
xsd/INSERT_HEADER_table.xsd|xsd/INSERT_LINEAS_table.xsd|xsd/mensajeEmail.xsd"> 
      <searchReplace> 
         <search>maquinaTest.com</search> 
         <replace>maquinaProd.com</replace> 
      </searchReplace> 
      <searchReplace> 
         <search>7777</search> 
         <replace>80</replace> 
      </searchReplace> 
      <searchReplace> 
         <search>eis/DB/TestejemploNonXA</search> 
         <replace>eis/DB/ProdnonXA</replace> 
      </searchReplace> 
      <searchReplace> 
         <search>eis/DB/EBS</search> 
         <replace>eis/DB/ProdEBS</replace> 
      </searchReplace> 
      <searchReplace> 
         <search>eis/DB/TestnonXA</search> 
         <replace>eis/DB/ProdnonXA</replace> 
      </searchReplace> 
      <searchReplace> 
         <search>eis/DB/TesteUsuarioInterface</search> 
         <replace>eis/DB/ProdXA</replace> 
      </searchReplace> 
   </wsdlAndSchema> 
</SOAConfigPlan> 

Aquí es dónde podemos hacer el intercambio de nombres para los Adaptadores, por ejemplo:

      <searchReplace> 
         <search>eis/DB/TestnonXA</search> 
         <replace>eis/DB/ProdnonXA</replace> 
      </searchReplace>

El Adapter en TEST podría ser eis/DB/TestnonXA y en PROD eis/DB/ProdnonXA.

Ahora bien, cómo adjuntar el Config Plan en un despliegue; si lo hacemos desde el JDEveloper, es muy simple, simplemente se realizan los pasos convenconales para su despliegue:

JDEveloper
Ilustración 2 - Deploy Composite

Escogemos la opción de Application Server:

Application Server Selection
Ilustración 3 - Application Server Selection

Posteriormente simplemente se debe escoger el Config Plan con el que quieres desplegar, dependiendo al ambiente que quieras apuntar:

Config Plan Selection
Ilustración 4 - Config Plan Selection

Lo mismo puedes hacer si sólo quieres generar el archivo .SAR:

Deploy to SAR
Ilustración 5 - Deploy to SAR

Al dar click en NEXT, también te permitirá escoger el Config Plan:

Config Plan Selection
Ilustración 6 - Config Plan Selection

De esta manera , al realizar un deployment, se adjunta el Config Plan, y el Engine por si solo realiza el intercambio de Datos.

También se puede hacer utilizando el Enterprise Manager:

Enterprise Manager Deploy
Ilustración 7 - Enterprise Manager Deploy

Después saldrá la siguiente pantalla:

Enterprise Manager Config Plan Selection
Ilustración 8 - Enterprise Manager Config Plan Selection

En la parte de abajo se puede ver que se puede escoger un Config Plan, de la misma manera que se hizo desde JDeveloper.

Otro punto relevante es que se pueden realizar pruebas del Config Plan, para validar que realmente haga los cambios necesarios. Esto se hace en el JDEV, dando click derecho sobre el archivo del Config Plan y escogiendo la opción de: Validate Config Plan

Validate Config Plan
Ilustración 9 - Validate Config Plan

.Esto generará un informe con los cambios que esperas se realicen al utilizar el Plan.

Por ejemplo:

[validateplan] 
[validateplan] Replace Location in file inserta_Datos_Reporte_AP_db.jca

[validateplan] 
[validateplan] 	connection-factory Old Value [ eis/DB/TestnonXA ] 

[validateplan] 		New Value [ eis/DB/ProdnonXA ] 

[validateplan] 
[validateplan] Replace Location in file INSERT_HEADER_db.jca

[validateplan] 
[validateplan] 	connection-factory Old Value [ eis/DB/OpUser ] 

[validateplan] 		New Value [ eis/DB/ProdnonXA ] 

[validateplan] 
[validateplan] Replace Location in file INSERT_LINEAS_db.jca

[validateplan] 
[validateplan] 	connection-factory Old Value [ eis/DB/OpUser ] 

[validateplan] 		New Value [ eis/DB/ProdnonXA ]
====

Se puede validar que los cambios que se quieren realizar, realmente se apliquen.

Con esto es muy práctico controlar los despliegues y promociones entre ambientes. Pareciera algo trivial pero en realidad tiene mucho valor y sentido en despliegues empresariales.


Publicado por Rolando Carrasco.