¡Hola!
En varios artículos, hablaré sobre las posibilidades de probar usando SoapUI cómo funcionan los servicios web 1C. También daré ejemplos de devolución de documentos 1C en formato PDF y archivos xml complejos. Algunas cosas son similares a aquí, pero repasaré ejemplos más complejos de cómo trabajar con servicios web. Pero primero, lo guiaré a través del proceso de iniciar servicios web y trabajar con SoapUI paso a paso para que sea más fácil descubrir cómo funcionan desde cero.
1. Servicio web sencillo
Para empezar, tomemos una configuración de esqueleto sin servicios web y analicemos el proceso de creación paso a paso.
Agreguemos un nuevo servicio web llamado test1 y creemos una operación de saludo en él con un tipo de cadena de retorno. Los nombres de los servicios web y las operaciones siempre deben configurarse en latín.
También debe configurar el URI del espacio de nombres y el nombre del archivo de publicación:
Al hacer clic en la lupa en el campo "Nombre del procedimiento", se abrirá el módulo del servicio web y podrá implementar la función de saludo.
hola() la función devuelve "cadena del servicio web 1s"; funciones finales
2. Publicación de un servicio web.
Ahora, para que la función resultante esté disponible a través de http, necesitamos publicar nuestro servicio en un servidor web. Apache 2.2 es adecuado para esto. Leí artículos sobre cómo configurar el trabajo con IIS y me pareció mucho más difícil. Después de instalar y ejecutar Apache 2.2, debe ir al menú Administración - Publicación en un servidor web. El campo 'directorio' debe completarse y contener el directorio de instalación de Apache. Recuerde los campos "nombre" y "dirección" del servicio web, nos serán útiles en el siguiente paso.
3. Prueba con SoapUI
Para probar, vamos a crear un usuario WsUser separado con una contraseña simple y darle todos los derechos.
Después de eso, instale y ejecute SoapUI. Este programa es muy conveniente para probar servicios web, puede obtener su descripción y realizar solicitudes posteriores a los servicios.
Vamos al menú Archivo - Nuevo proyecto SOAP, establecemos el nombre del proyecto hellotest y en el campo Inicial WSDL escribimos el siguiente enlace:
http://localhost/test_ws/ws/test1.1cws?wsdl
En él, la parte "test_ws" se especificó en la última etapa en el campo "nombre" y test1.1cws en el campo "dirección".
Haga clic en Aceptar y, en esta etapa, deberá iniciar sesión iniciando sesión con el usuario de prueba WsUser. Se creará un proyecto y dos elementos vinculantes.
Soap12Binding es diferente porque funciona en nueva versión Estándar SOAP 1.2. Abramos el elemento Request1 en test1Soap12Binding y veamos esto:
SoapUI muestra qué xml se pasará a nuestra función. Antes de ejecutar la prueba, hay un matiz más, por defecto, SoapUI requerirá autorización para cada elemento de Solicitud individual. Por lo tanto, para no configurarlo cada vez, debe hacer clic con el botón derecho en testSoap12Binding, seleccionar Mostrar vista de interfaz y, en la ventana que se abre, en la pestaña "Punto final del servicio", establecer el nombre y la contraseña del usuario de los servicios web:
Si esto no se hace, entonces para cada solicitud deberá configurar la autorización, en el panel inferior, haga clic en el botón Auth.
Ahora finalmente podemos hacer una solicitud a la función hola y ver la respuesta:
¡Genial, todo funcionó!
4. Pasar parámetros simples a una función.
Ahora hagamos nueva caracteristica con parámetros, por ejemplo, verificaremos el trabajo con fechas, haremos la función getSaleDocNumbersByDate, que aceptará la fecha del documento (factura) y devolverá los números de documento para esta fecha como una cadena. Agreguemos el parámetro de fecha con el tipo dateTime a la operación:
el código es así:
función getSaleDocNumbersByDate(fecha) //FechaInicio = DíaInicio(fecha); fecha de finalización = día de finalización (fecha); selección de Documentos = documentos.Gastos.Seleccionar(Fecha de inicio, Fecha de finalización); numeros=""; while Selección de documentos.Next() number loop = números+"#"+Selección de documentos.Número+";"; fin de ciclo; retorno de número; funciones finales
Ahora en SoapUI, haga clic con el botón derecho en el elemento testSoap12Binding y seleccione Actualizar definición. Después de eso, la función getSaleDocNumbersByDate y una solicitud lista aparecerán en el proyecto. Para completar la fecha, debe usar el formato "YYYY-MM-DDThh: mm: ss" (puede consultar w3schools y recomendamos ENCARECIDAMENTE usar este sitio para comprender cómo trabajar con xml)
Luego obtenemos la siguiente solicitud y respuesta:
5. Paquetes XDTO
Si es necesario pasar parámetros más complejos a las funciones (por ejemplo, xml con varios campos), o recibir xml complejo en respuesta, entonces no podemos prescindir de los paquetes XDTO.
El trabajo con XDTO se trata con gran detalle en una serie de artículos. De hecho, el paquete define la estructura y el tipo de campos utilizados en los archivos xml.
Consideraré un ejemplo de pasar y recibir un archivo xml cuyo tipo se define en el paquete
Y también en los siguientes artículos consideraré ejemplos:
- transferir a 1s un archivo xml no descrito en el paquete en formato base64
- obtener de 1s un documento pdf en formato base64 y decodificarlo
- obteniendo de 1s xml-file con una estructura anidada de elementos y determinando su número
6. Transfiera a 1s en el parámetro del archivo xml, cuyo tipo se define en el paquete.
La tarea será la siguiente: encontrar el documento de la factura por el número y la fecha especificados en el xml entrante y devolver el documento encontrado. También se debe devolver en forma de xml con el número, fecha, contraparte y su código y la parte tabular de la mercancía.
Vamos a crear un paquete paquete1 con el espacio de nombres paquete1_ns. Para el archivo xml entrante, definamos el tipo de objeto InDocSaleQuery con el campo numérico del tipo cadena y el campo de fecha del tipo dateTime. Para el archivo de salida, primero definamos el tipo para una fila de la parte tabular de los productos: SaleItem con los campos nombre del tipo de cadena, suma de precio y cantidad de tipo decimal. Y el documento SaleDoc en sí será de un tipo compuesto: los campos de número, fecha, nombre de socio y el campo SaleItems que tendrá el tipo SaleItem y el número máximo -1. Es este campo lo que significa que puede contener una matriz de varios elementos. Así es como se ve en la configuración:
Primero demostraré el código de la función, y solo luego explicaré lo que sucede.
El código:
función getSaleDoc(incomingXML)DocNumber = incomingXML.number; DateDoc = incomingXML.fecha; solicitud = nueva solicitud; query.Text = "SELECT | ConsumableProducts.Nomenclature.Name as name, | ConsumableProducts.Price as price, | ConsumableProducts.Quantity as cantidad, | ConsumableProducts.Amount as sum, | ConsumableProducts.Reference | FROM | Document.Consumable.Products AS ConsumableProducts |WHERE | ConsumableProducts.Reference.Number = &Number | And ConsumableProducts.Reference.Date = &DateDoc"; consulta.SetParameter("Número",númerodoc); consulta.SetParameter("DateDoc",DateDoc); buscar = consulta.Ejecutar().Seleccionar(); si fetch.Quantity()=0 entonces //devuelve un errorDocumentType = FactoryXDTO.Type("packet1_ns", "SaleDoc"); DocumentPackage = XDTO Factory.Create(DocumentType); DocumentPackage.number = "¡No se encontraron documentos!"; Documento de paquete de devolución; de lo contrario //crear tiposDocumentType = FactoryXDTO.Type("packet1_ns", "SaleDoc"); TablePartType = XDTO Factory.Type("packet1_ns", "SaleItem"); DocumentPackage = XDTO Factory.Create(DocumentType); //seleccionar de la parte tabular sch=0; hasta que el bucle selection.Next() si cn=0 luego //llene los detalles del documento doc = selection.link; PaqueteDocumento.número = documento.Número; PaqueteDocumento.fecha = doc.Fecha; PaqueteDocumento.partnerName = string(doc.Cuenta); terminara si; //Complete la tabla partTablePartPackage = XDTO Factory.Create(TablePartType); FillPropertyValues(TablePartPackage, selección); //añadirlo a documentDocumentPackage.SaleItems.Add(TablePartPackage); cn=cn+1; fin de ciclo; Documento de paquete de devolución; terminara si; funciones finales
Hay dos puntos principales aquí. Primero: dado que se estableció el tipo del parámetro entrante incomingXML y este tipo se declaró en el paquete, es posible acceder inmediatamente a los campos de este xml entrante. Segundo: trabajar con la fábrica XDTO. A partir de él se obtuvo el tipo para los parámetros de salida resultantes y se creó un XDTOValue de este tipo, en el que se llenaron los campos necesarios. También vale la pena señalar que en el tipo SaleDoc, debe ingresar un campo separado para el error, pero para fines de prueba, los errores se registrarán en el campo numérico.
Así es como se ve el resultado de esta solicitud en SoapUI:
Como puede ver, todo funciona, pero todavía hay algo que mejorar; por ejemplo, me gustaría saber cuántos elementos SaleItems tenemos en el documento.
Hablaré de esto y de ejemplos más complejos en el próximo artículo.
En el archivo adjunto: descargando la base de datos y el proyecto SoapUI.
Uso de la herramienta de validación de servicios web para WSDL y SOAP
Aparentemente, con la llegada de nuevas tecnologías y estándares como XML y HTTP, los servicios web han asegurado su lugar en el panteón de la innovación en Internet. Pero, ¿cómo surgió esta innovación?
El concepto básico de los servicios web se remonta a mediados de la década de 1960 en los EE. UU. En la industria del transporte, por ejemplo, en empresas ferroviarias y navieras, nuevo concepto intercambio electrónico de datos entre computadoras, que se desarrolló aún más en la tecnología EDI (Electronic Data Interchange - intercambio electrónico de datos). Escuché por primera vez sobre EDI de un profesor de escuela de negocios en 1980.
En 1996, el Instituto Nacional de Estándares y Tecnología de EE. UU. anunció un estándar para EDI en las Publicaciones Federales de Estándares de Procesamiento de la Información (FIPS PUB 161-2). De acuerdo con la especificación publicada, EDI es un estándar para intercambiar mensajes fuertemente formateados entre computadoras. El procesamiento de los mensajes recibidos lo lleva a cabo únicamente la computadora, y estos mensajes generalmente no están destinados a la interpretación humana. Eso es exactamente lo que hacen los servicios web, excepto que a mediados de la década de 1960, XML, Internet y la World Wide Web no existían.
Para aquellos que no están muy familiarizados con los servicios web, revisaré brevemente las definiciones y los componentes principales de los servicios web.
¿Qué son los servicios web?
Un servicio web es un sistema de software diseñado para admitir interacciones máquina a máquina entre recursos informáticos en una red y utiliza mensajes SOAP (Protocolo simple de acceso a objetos) definidos por el World Wide Web Consortium.
El Protocolo simple de acceso a objetos (SOAP) es un protocolo simple y extensible para intercambiar mensajes estructurados y escritos en un entorno de red distribuido y descentralizado. Los mensajes SOAP están escritos en el formato Extensible Markup Language (XML), un formato de texto simple y flexible derivado del Standard Generalized Markup Language (SGML) desarrollado por la Organización Internacional de Normalización (ISO 8879:1986).
El lenguaje de descripción de servicios web (WSDL) es un lenguaje basado en XML que describe la interfaz de los servicios web.
¿Qué sucede cuando se intercambian mensajes SOAP erróneos? ¿Qué pasaría si un mensaje SOAP erróneo fuera procesado sin previo aviso e incluso utilizado para generar información para la toma de decisiones?
En la práctica, es imposible saber si los datos de un mensaje SOAP son correctos o no. Sin embargo, puede validar la validez de un mensaje SOAP mirando su definición de interfaz o WSDL.
A vida real depurar problemas en mensajes SOAP es muy difícil. Si hay un error en el mensaje SOAP, el servidor de servicios web recibe un código de respuesta HTTP 500. Los servidores de servicios web no proporcionan información detallada sobre qué parte del mensaje SOAP tiene un problema. Puede encontrarse con una situación aún peor en la que se reciben respuestas SOAP correctas del servidor de servicios web sin ningún mensaje de error, y ni usted ni sus servidores de servicios web pueden comprender los problemas en sus solicitudes y respuestas SOAP. Por ejemplo, desea consultar el precio actual de las acciones de la empresa B, pero envió un mensaje SOAP con etiquetas mal escritas al servidor de servicios web. El servidor de servicios web puede ignorar las etiquetas incorrectas y proporcionar un valor predeterminado en el mensaje de respuesta SOAP, como el precio de las acciones de la empresa A. Si esto pasa desapercibido, las consecuencias pueden ser desastrosas.
Estos tipos de problemas se pueden prevenir pronto con la herramienta de validación de servicios web para WSDL y SOAP. Le permite validar mensajes SOAP mediante el lenguaje de definición de servicios web (WSDL) antes de implementar aplicaciones que utilizan el servicio web. El programa analiza la sintaxis y la corrección de sus mensajes SOAP con WSDL y señala los problemas al informar los errores y los números de línea en detalle. Como resultado, ya no recibe molestos mensajes HTTP 500. ¿Están encriptados sus mensajes SOAP? No hay problema. El programa los descifrará y comprobará por usted la exactitud de los mensajes SOAP descifrados.
Este programa se creó para ayudar al personal de soporte de IBM Web Services a resolver problemas relacionados con los servicios web en IBM® WebSphere Application Server de los que informan clientes de todo el mundo. El programa está diseñado para verificar la corrección de los mensajes SOAP. Si el mensaje SOAP tiene una firma digital, el programa también la verificará. Con la herramienta de validación de servicios web para WSDL y SOAP, puede incluso enviar mensajes SOAP a servidores de servicios web y recibir mensajes de respuesta SOAP. El programa fue creado para eliminar problemas en la operación industrial al usarlo en primeras etapas desarrollo, así como para reducir el tiempo de resolución de problemas que se presenten durante la operación.
Crearemos un servicio web muy simple. Primero crearemos una aplicación Java™ sencilla. Después de probar la aplicación Java, usamos IBM Rational® Application Developer for WebSphere® Software para generar un servicio web. A continuación, realizaremos algunos cambios en el servicio web generado. Finalmente, usamos la herramienta de validación de servicios web para WSDL y SOAP para crear, validar, enviar y recibir mensajes SOAP.
Se puede crear un servicio web simple utilizando IBM Rational Application Developer para WebSphere Software. Los servicios web se pueden crear de dos maneras:
- Desarrollo top-down Desarrollo en el que se generan clases Java que implementan servicios Web a partir de WSDL.
- Desarrollo ascendente, en el que se genera un servicio web a partir de un bean Java o un bean Java empresarial.
En el siguiente ejemplo, implementaremos un servicio web utilizando el método de desarrollo ascendente. Primero, crearemos una aplicación Java simple. A continuación, generaremos un servicio web Java Bean a partir de una aplicación Java utilizando el programa IBM Rational Application Developer para WebSphere Software.
Creación de una aplicación Java
Primero, crearemos una aplicación Java que emita un saludo. Si no se proporciona ningún nombre, la aplicación devolverá el texto "¡Hola, amigo!". Si se proporciona un nombre, la aplicación devolverá el texto "Hola", seguido de ese nombre. A continuación se muestra el código de la aplicación Java DemoWebService que se encuentra en el paquete de demostración. El método hello() devuelve una cadena según el nombre.
Listado 1. DemoWebService.java
/* * @autor: Jinwoo Hwang * Copyright 2010 IBM Corporation */ paquete de demostración; public class DemoWebService ( public String hola(String nombre) ( si (nombre == nulo) devuelve "¡Hola, amigo!"; de lo contrario, devuelve "Hola, " + nombre + "!"; ) )Pruebas de aplicaciones Java
Es muy importante probar una aplicación Java antes de crear un servicio web a partir de ella. Para iniciar una aplicación, puede escribir una clase con un método main(). También puede utilizar la funcionalidad Universal Test Client proporcionada por IBM Rational Application Developer v7 para realizar pruebas rápidamente sin escribir código de prueba. Simplemente seleccione Universal Test Client en el menú contextual de la clase Java para iniciar Test Client.
- En Universal Test Client, expanda Objetos > DemoWebService.
- Elegir método Hola.
- Introduzca una cadena o su nombre en el campo valor y presiona el boton Invocar.
También puede probar con el parámetro nulo y ver qué sucede. Si se pasa nulo al método hello(), se devuelve la cadena "¡Hola, amigo!", como se esperaba.
Creación de un servicio web
Hasta ahora todo está funcionando bien. Comencemos a generar un servicio web a partir de una clase Java utilizando el método de desarrollo de servicios web de abajo hacia arriba.
- Seleccione la aplicación Java DemoWebService y cree un nuevo servicio web desde IBM Rational Application Developer.
- Ya que hemos creado una clase Java, seleccione Servicio web de bean Java de abajo hacia arriba en la lista de tipos de servicios web. Seleccione iniciar cliente y presiona el boton Finalizar. Si tuviéramos una clase EJB, también podríamos escribir un EJB (Java Enterprise bean) para generar un servicio web.
Si todo salió bien, verá el DemoWebServiceDelegate.java generado en Recursos de Java junto a DemoWebService.java.
Al mirar DemoWebServiceDelegate.java, puede encontrar la anotación del servicio web Java @javax.jws.WebService que especifica el targetNamespace, serviceName y portName en la clase DemoWebServiceDelegate. Se crea una instancia de DemoWebService y otro método hello() a partir del método hello() de DemoWebService. Si desea obtener más información sobre las anotaciones de servicios web de Java, consulte Solicitud de especificación de Java (JSR) 181, Metadatos de servicios web para la plataforma Java.
Listado 2. DemoWebServiceDelegate.java
/* * @autor: Jinwoo Hwang * Copyright 2010 IBM Corporation */ paquete de demostración; @javax.jws.WebService(targetNamespace = "http://demo/", serviceName = "DemoWebServiceService", portName = "DemoWebServicePort") public class DemoWebServiceDelegate (demo.DemoWebService _demoWebService = new demo.DemoWebService(); public String hola( Nombre de cadena) ( return _demoWebService.hello(name); ) )Creación de un WSDL
En un proyecto de programa cliente, también puede encontrar que se han generado los archivos DemoWebServiceService.wsdl y DemoWebService_schema1.xsd. DemoWebServiceService.wsdl contiene información en el lenguaje de definición de servicios web que describe los servicios de red para la aplicación Java que creó anteriormente. DemoWebServiceService_schema1.xsd contiene un esquema XML que describe la estructura de los tipos de datos utilizados en los mensajes SOAP.
Al mirar el archivo DemoWebServiceService.wsdl, puede ver que tiene un conjunto de elementos de definiciones en su raíz. Hay 6 elementos en el elemento de definiciones:
- tipos (tipos);
- mensaje (mensaje);
- portType (tipo de puerto);
- vinculante (vinculante);
- servicio (servicio);
- puerto (puerto).
tipos define los tipos de datos utilizados en el intercambio de mensajes. En DemoWebServiceService.wsdl, importamos DemoWebServiceService_schema1.xsd en lugar de definir tipos de datos en un archivo WSDL.
mensaje define los mensajes a intercambiar. Tenemos 2 mensajes: "hola" y "holaRespuesta". El mensaje de saludo tiene una parte llamada "parámetros". Esta parte tiene un elemento "tns:hello". El mensaje helloResponse tiene una parte llamada "parámetros" que es lo mismo que hello. Esta parte tiene un elemento "tns:helloResponse". Los elementos hello y helloResponse se definen en el archivo DemoWebServiceService_schema1.xsd. Los revisaremos en breve.
Tipo de puerto– Operaciones soportadas por puntos extremos. Cada operación proporciona un mensaje de entrada y salida. Nuestra operación "hola" consta de un mensaje de entrada "tns:hola" y un mensaje de salida "tns:holaRespuesta". Estas operaciones corresponden a un intercambio de solicitud-respuesta. WSDL proporciona 4 primitivas de intercambio de punto final diferentes:
- unidireccional (unidireccional);
- solicitud-respuesta (solicitud-respuesta);
- solicitud-respuesta (demanda-respuesta);
- notificación (notificación).
En un intercambio unidireccional, el punto final solo recibe el mensaje. En un intercambio de solicitud-respuesta, un punto final recibe un mensaje y envía el mensaje correspondiente. En un intercambio de solicitud-respuesta, un punto final envía un mensaje y recibe el mensaje correspondiente. En un intercambio de notificaciones, el punto final solo envía un mensaje.
Unión define los detalles del protocolo y las especificaciones de formato de mensaje para operaciones y mensajes especificados por el tipo de puerto. Para el atributo de estilo, usamos el documento de valor. El atributo de estilo proporciona 2 estilo diferente mensajes: rpc y document. En estilo rpc, los mensajes contienen parámetros y valores de retorno. En el estilo de documento, los mensajes contienen documentos. El atributo de transporte especifica el URI para el transporte SOAP. El valor especificado http://schemas.xmlsoap.org/soap/http significa que la especificación SOAP utilizará el enlace HTTP. El URI para el encabezado HTTP SOAPAction para el enlace HTTP SOAP se especifica en el atributo soapAction. Debido a que se utiliza el enlace SOAP HTTP, se requiere el valor del atributo soapAction. Para el atributo soapAction, usamos la cadena vacía "". El elemento soap:body define cómo se ensamblan las partes del mensaje dentro del elemento del cuerpo del mensaje SOAP. El atributo de uso proporciona 2 varias opciones: literal (literal) y codificado (codificado). Estamos usando literal. Esto significa que hemos elegido la definición esquema especifico, utilizando el atributo de tipo o el elemento. La variante codificada utiliza un tipo abstracto con reglas de codificación.
Servicio define el conjunto de puertos a utilizar.
Puerto define el punto final de comunicación especificando la dirección de red a la que enlazarse.
dirección de red para enlazar. En nuestro caso, la dirección del extremo de SOAP es http://localhost:9081/HelloWorldWSProject/DemoWebServiceService.
Listado 3. DemoWebServiceService.wsdl
Creación de esquemas
Importamos DemoWebServiceService_schema1.xsd desde DemoWebServiceService.wsdl. Considere el archivo DemoWebServiceService_schema1.xsd. Está escrito en el lenguaje de definición de esquemas XML para describir la estructura y las limitaciones del contenido de los documentos XML. Tenemos 2 elementos: hello y helloResponse. Cada elemento tiene un tipo. El tipo hola tiene un elemento "arg0" que es una cadena. El elemento "arg0" es opcional porque el valor del atributo minOccurs en su declaración es 0. Si el atributo minOccurs se establece en 1 o más, se debe especificar el elemento. Lo mismo ocurre con el elemento "return" en el tipo helloResponse.
Listado 4. DemoWebServiceService_schema1.xsd
Primeros pasos con la herramienta de validación de servicios web para WSDL y SOAP
Así que hemos cubierto el WSDL y el esquema. Iniciemos el servidor de servicios web para que podamos invocar el servicio web desde la herramienta de validación de servicios web para WSDL y SOAP.
Para ejecutar la herramienta de validación de servicios web para WSDL y SOAP, necesita el entorno de tiempo de ejecución Java 6 (o posterior) y las API de digitalización y descodificación de XML que se ajustan a las especificaciones de procesamiento y sintaxis de cifrado XML del World Wide Web Consortium (http:// www.w3.org/TR/xmlenc-core/).
IBM Java 6 proporciona una implementación de JSR 106: API de cifrado digital XML. Si ha instalado sistema IBM Java 6 significa que todo está listo para funcionar y no necesita instalar nada más.
Si su entorno de tiempo de ejecución Java 6, como Sun Microsystems™ Java 6, no tiene API de cifrado digital XML, debe instalar bibliotecas que implementen JSR 106 o el paquete Apache™ XML Security versión 1.4.3, que se puede descargar desde http: / /santuario.apache.org/ . Simplemente descargue la distribución binaria, descomprímala en un directorio y dígale a la herramienta dónde está ese directorio usando las opciones de línea de comandos -vmargs y -DAXS.
En el momento de redactar este documento, la herramienta de validación de servicios web para WSDL y SOAP es compatible con JSR 106 y Apache XML Security versión 1.4.3 para el cifrado y descifrado digital XML. Si desea verificar firmas digitales en mensajes SOAP, necesita bibliotecas que implementen JSR 105: API de firma digital XML. Afortunadamente, las máquinas virtuales Java 6 de Sun Microsystems e IBM proporcionan implementaciones de JSR 105. Esta es la razón por la que se eligió Java 6 como el requisito mínimo para un entorno de tiempo de ejecución de Java. Si su entorno Java 6 no proporciona bibliotecas que implementen JSR 105, debe encontrarlas.
La herramienta de validación de servicios web para WSDL y SOAP se puede descargar aquí de forma gratuita. Su instalación es muy sencilla. Descomprima el paquete en un directorio y ejecute wsvt.exe. Si tu máquina virtual Java no es un entorno Java 6 predeterminado que admita firmas digitales XML y cifrado y descifrado digital; debe especificar la ubicación de Java 6 con la opción -vm, por ejemplo:
wsvt -vm c:\IBMjava6\bin\java.exe
Nuevamente, si tiene IBM Java 6, no necesita instalar nada más. Todo lo que necesita ya está incluido en IBM Java 6. Al utilizar Java 6 de Sun Microsystems, debe indicarle al programa la ubicación de Apache XML Security para descifrar los mensajes SOAP cifrados.
Por ejemplo, el siguiente comando ejecutará un programa con Sun Java 6 y la biblioteca Apache XML Security versión 1.4.3 ubicada en el directorio C:\xml-security-1_4_3\libs:
wsvt –vm c:\SUNjava6\bin\java.exe –vmargs –DAXS=C:\xml-security-1_4_3\libs
La siguiente es una lista de los archivos de la biblioteca de seguridad XML de Apache que utiliza la herramienta de validación de servicios web para WSDL y SOAP, aunque la versión de seguridad XML de Apache 1.4.3 se envía con 9 archivos jar:
Commons-registro.jar;
serializador.jar;
xalan.jar;
xmlsec-1.4.3.jar.
El MANIFEST.MF de la herramienta de validación de servicios web para WSDL y SOAP contiene la siguiente información:
Paquete-Política de activación: perezoso
Paquete-ClassPath: .,
externo:$AXS$/commons-logging.jar,
externo:$AXS$/serializer.jar,
externo:$AXS$/xalan.jar,
externo:$AXS$/xmlsec-1.4.3.jar
Por eso fue necesario especificar --vmargs --DAXS=C:\xml-security-1_4_3\libs para que Sun Java 6 descifrara los mensajes SOAP cifrados.
He pasado bastante tiempo resolviendo conflictos de carga de clases e incompatibilidades entre las clases relacionadas con XML que se encuentran en Sun Java Runtime Environment, Apache XML Security y algunos complementos de Eclipse. Configurar el entorno de tiempo de ejecución de IBM Java fue pan comido porque se entrega con la implementación JSR 106 y no requiere Apache XML Security.
crear un proyecto
Ahora, después de configurar y ejecutar el programa de la herramienta, puede crear nuevo proyecto. Un proyecto puede contener un archivo WSDL, varios archivos de esquema asociados con el archivo WSDL y mensajes SOAP en archivos XML. Si un proyecto tiene varios archivos WSDL, solo se usa uno de ellos y los demás se ignoran al validar el archivo XML del mensaje SOAP. Para usar un archivo WSDL diferente, debe crear un proyecto separado. Cada mensaje SOAP debe estar contenido en un archivo con extensión .xml, de lo contrario no será tratado como un mensaje SOAP.
- Haga clic derecho y seleccione Nuevo > Proyecto.
- Seleccione proyecto en General.
- Introduzca "Proyecto de prueba" en el campo nombre del proyecto y presiona el boton Finalizar.
Importar WSDL y esquema
Hemos creado un "Proyecto de prueba". Ahora puede importar WSDL y XSD en él.
- Seleccione el proyecto y luego, desde el menú contextual, seleccione Importar.
- Seleccione Sistema de archivos en General.
- Seleccione el directorio donde se almacenan el WSDL y el XSD.
- Seleccione 2 archivos (DemoWebServiceService.wsdl y DemoWebServiceService_schema1.xsd) y haga clic en el botón Finalizar.
Descripción general de WSDL y esquemas
Ahora tenemos un proyecto con WSDL y XSD. Puede hacer doble clic con el botón izquierdo del mouse en un WSDL para ver el WSDL en el modo Diseño y en el modo Fuente. En el modo Diseño, puede representar un servicio web con entradas y salidas.
En el modo Fuente, puede ver y editar el WSDL en un editor de texto.
Si los archivos XSD no se pueden abrir en el editor XSD, se pueden abrir en el editor XML seleccionando Abrir con > Editor XML en el menú contextual de ese archivo XSD.
Hemos abierto DemoWebServiceService_schema1.xsd en un editor XML.
Creación de un mensaje SOAP
Entonces tenemos el WSDL y el esquema listos para validar los mensajes SOAP. Empecemos a probar la herramienta de validación de servicios web para WSDL y SOAP con un mensaje SOAP. Debe incluir el mensaje SOAP en el proyecto. El mensaje SOAP debe estar contenido en un archivo con extensión .xml para que pueda ser validado.
- Seleccione Nuevo > XML para crear un mensaje SOAP en un proyecto.
- Seleccione proyecto de prueba para la carpeta principal del nuevo mensaje SOAP. Si el archivo aún no está seleccionado, ingrese "DemoSOAPMessage.xml" en el campo Nombre del archivo y presiona el boton Finalizar.
El programa llama automáticamente al editor XML con el nuevo archivo XML. No contiene nada más que una cadena con la versión y la codificación xml. Es bueno que tengamos al menos algo antes de comenzar a crear un mensaje SOAP desde cero. ¿Sabes cómo redactar un mensaje SOAP? No te preocupes. En la siguiente sección, recorreremos los pasos para crearlo.
Para crear un mensaje SOAP, puede invocar el servicio "hola" usando el parámetro "parámetros" con mi nombre - "Jinwoo". Por supuesto que puedes usar tu nombre de pila. Se utiliza el espacio de nombres http://demo/. Tenga cuidado: se escribe como http://demo/ , no como http://demo , eso es esencial.
Listado 5. HelloWorldSOAPmessage.xml
¿Ves problemas en este mensaje SOAP? Si es así, no te preocupes. Nos ocuparemos de esto más adelante.
Envío de un mensaje SOAP
¿Está listo para enviar un mensaje al servidor de servicios web?
- Seleccione el mensaje SOAP y seleccione
- En la ventana Transmitir solicitud SOAP y Recibir respuesta SOAP, puede completar Dirección de Servicio, SOAPAction y tipo de contenido. A esta aplicación no necesitamos especificar SOAPAction porque usamos la cadena vacía "" para el atributo soapAction en la sección de enlace del archivo DemoWebServiceService.wsdl.
- Ingrese http://localhost:9081/HelloWorldWSProject/DemoWebServiceService en el campo Dirección de Servicio si el servidor se ejecuta en la máquina local en el puerto localhost:9081. En caso contrario, deberá introducir la dirección real donde está disponible el servicio Web.
- Seleccione texto/html para el campo tipo de contenido.
- Haga clic en el botón OK para enviar un mensaje SOAP al servidor.
Recibir un mensaje SOAP
Si el servidor está en funcionamiento, debería recibir una respuesta SOAP. Si no recibe respuesta, verifique que la dirección y el tipo de contenido sean correctos.
Validación de mensajes SOAP
¡Excelente! Hemos aceptado una respuesta SOAP. También se guarda en el proyecto. Pero espera. ¿Ves que algo anda mal? Tenemos "¡Hola, amigo!" en lugar de "¡Hola, Jinwoo!". ¿Algo salió mal? ¿No tienen idea?
Desafortunadamente, el servidor de servicios web no nos dejó saber qué estaba mal. Sin advertencias. La situación en la que se envían respuestas SOAP impredecibles y el servidor de servicios web no tiene idea de lo que está fallando puede ser muy peligrosa. Incluso los destinatarios de las respuestas SOAP pueden no notar problemas en el mensaje SOAP en cuestión.
La herramienta de validación de servicios web para WSDL y SOAP lo ayuda a determinar qué está fallando.
Listado 6. Respuesta
- Seleccione el mensaje de respuesta SOAP y haga clic en el botón Validar.
La herramienta de validación de servicios web para WSDL y SOAP encontró un error en el mensaje SOAP.
Mensaje SOAP no válido: cvc-complex-type.2.4.a: Se encontró contenido no válido que comienza con el elemento "parámetros". Se espera uno de "(arg0).
Edición de un mensaje SOAP
- El programa se queja del valor de los "parámetros". Cámbielo a arg0 y guárdelo.
Listado 7. Mensaje SOAP modificado
- Compruebe la corrección del mensaje de respuesta SOAP modificado. No aparecen más mensajes de error.
- Ahora estamos listos para enviar el mensaje de respuesta modificado al servidor. Seleccione mensaje SOAP y luego seleccione Transmitir solicitud SOAP y recibir respuesta SOAP.
- En la ventana Transmitir solicitud SOAP y Recibir respuesta SOAP, ingrese http://localhost:9081/HelloWorldWSProject/DemoWebServiceService en el campo Dirección de Servicio si el servidor se ejecuta en el puerto localhost:9081.
- Seleccione texto/html para el campo tipo de contenido y presiona el boton OK.
Esta vez, como era de esperar, llega la respuesta correcta.
Listado 8. Respuesta SOAP
Detección del espacio de nombres incorrecto
¿Qué sucede si envía un mensaje con el espacio de nombres incorrecto?
- Cambie el espacio de nombres a http://demo2/ y guarde el mensaje.
Listado 9. Cambiando el espacio de nombres
- A continuación, puede enviar una solicitud al servidor.
Verá una IOException: el servidor devolvió el código de respuesta HTTP: 500 para URI: http://localhost:9081/HelloWorldWSProject/DemoWebServiceService.
El servidor de servicios web devolvió información sobre IOException en la respuesta, pero esta información no es suficiente para detectar el error. Verifique la corrección del mensaje usando la herramienta si desea obtener más detalles para resolver el problema.
El programa dice: "Mensaje SOAP no válido: cvc-complex-type.2.4.a: Se encontró contenido no válido que comienza con el elemento 'ns0: hola". Se espera uno de "("http://demo/":hello,"http://demo/":helloResponse)".
Este mensaje indica que se espera http://demo/. Es esto, y no el código de respuesta HTTP 500, lo que necesitamos saber.
Validación de mensajes SOAP cifrados
¿Qué sucede si sus mensajes SOAP están encriptados? No hay problema si tiene claves y contraseñas. Simplemente seleccione un mensaje SOAP y Validar de la misma manera que se hace para cualquier otro mensaje SOAP regular. Si su mensaje SOAP está encriptado, aparecerá en la pantalla un mensaje similar al que se muestra en la Figura 35.
En el momento de escribir este artículo, se admiten 3 tipos de almacenes de claves (keystore):
- Almacén de claves Java (JKS).
- Almacén de claves de extensión de criptografía de Java (JCEKS).
- Estándar de sintaxis de intercambio de información personal (Estándares criptográficos de clave pública n.º 12).
Debe proporcionar información sobre su almacén de claves: nombre de archivo, tipo de archivo y contraseña. Si la información es correcta, debe seleccionar una clave y una contraseña. También puede encontrar información sobre sus almacenes de claves y la lista de claves y certificados en el almacén de claves, como el tipo de almacén de claves, el nombre del proveedor, la versión del proveedor, la información del proveedor, el tipo de clave, la fecha de creación, el tipo de certificado, el algoritmo y el formato.
Si toda la información es correcta, el programa generará un mensaje SOAP descifrado y comprobará si es correcto.
Actualmente soportado los siguientes algoritmos cifrado:
- Estándar de cifrado avanzado (AES) en modo Cipher Block Chaining (CBC) con vector de inicialización (128/192/256 bits).
- Cifrado de clave de estándar de cifrado avanzado (AES) (128/192/256 bits).
- Algoritmo de cifrado de datos triple Modos de operación (triple-DES) Cifrado de claves.
- Modos de operación del algoritmo de cifrado de datos triple (triple-DES) Cifrado de claves en el modo Cipher Block Chaining (CBC).
- Especificaciones de criptografía RSA Versión 1.5.
- El relleno de cifrado asimétrico óptimo (OAEP) de RSA es un método con una función de generación de máscaras.
Validación de mensajes SOAP firmados digitalmente
¿Qué sucede si su mensaje SOAP está firmado digitalmente? Simplemente seleccione el mensaje SOAP y luego seleccione Verificación de firma digital de mensaje SOAP.
Si la firma digital es correcta, verá la siguiente pantalla:
De lo contrario, el programa informará de un error en la firma. Actualmente se admiten las siguientes especificaciones y algoritmos de firma digital:
- Algoritmo hash seguro 1 (SHA-1)
- Código de autenticación de mensajes hash (HMAC)
- Algoritmo de firma digital (DSA)
- Estándares de criptografía de clave pública (PKCS #1)
- Algoritmo de cifrado RSA con algoritmo hash seguro (SHA-1)
- XML canónico versión 1.0 y 1.1
- Transformaciones XSL (XSLT) Versión 1.0
- Lenguaje de ruta XML (XPath) Versión 1.0
- Base64
Acceso al Servicio Meteorológico Nacional de EE. UU. mediante un mensaje SOAP
El servicio web simple que creamos y probamos funciona bien. ¿Es posible usar este programa en un entorno "real"? Puede intentar trabajar con el servicio web real de la Oficina Meteorológica Nacional de los EE. UU. proporcionado por los EE. UU. Administración Nacional Oceánica y Atmosférica (NOAA).
- Crea un proyecto.
- Cree el XML del mensaje SOAP.
La Oficina Meteorológica Nacional de EE. UU. proporciona muchos servicios web diferentes. Puede intentar trabajar con el servicio NDFDgenByDay, que proporciona pronósticos meteorológicos para un punto con una latitud y longitud determinadas.
Para acceder a NDFDgenByDay, debe proporcionar la siguiente información:
Tabla 1. NDFDgenByDay
| Nombre del servicio (nombre del servicio) | NDFDgenByDay |
|---|---|
| Punto final (punto final) | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
| SoapAction (acción SOAP) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
| encodingStyle (estilo de codificación) | http://schemas.xmlsoap.org/soap/encoding/ |
| Espacio de nombres (espacio de nombres) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl |
| latitud (latitud) | Número decimal |
| longitud (longitud) | Número decimal |
| startDate (fecha de inicio) | la fecha |
| numDays (número de días) | Entero |
| formato (formato) | Línea |
En este ejemplo, queremos crear una solicitud SOAP para obtener un pronóstico semanal para una ubicación con coordenadas (LAT38.9,LON-77.01) a partir del 23 de julio de 2010 en formato de 24 horas:
Listado 10. Solicitud SOAP
No especificamos un espacio de nombres porque el servicio funcionaba sin uno. Si hay algún problema con el espacio de nombres, configúrelo.
Seleccione un mensaje y Transmitir solicitud SOAP y recibir respuesta SOAP en la herramienta de validación de servicios web para WSDL y SOAP.
Tabla 2. Solicitud de información
| Nombre | Sentido |
|---|---|
| Punto final (punto final) | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
| SoapAction (acción SOAP) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
| tipo de contenido (tipo de contenido) | texto/xml; conjunto de caracteres = utf-8 |
Ahora los datos de pronóstico son mucho más fáciles de leer.
Si este consejo no le parece correcto, puede usar su propio método de formato HTML. La mayoría de los servicios web ofrecen resultados en formato XML, por lo que no tiene que usar este truco todo el tiempo.
Conclusión
Hemos creado, convertido, recibido y validado mensajes SOAP utilizando la herramienta de validación de servicios web para WSDL y SOAP. Este programa le permite identificar problemas que la mayoría de los servidores de servicios web ni siquiera pueden detectar, lo que puede tener graves consecuencias en la vida real. El uso de este programa en la etapa de desarrollo le permite reducir el tiempo para solucionar problemas durante la operación.
Servicios web en 1C
Este artículo considerará la integración de 1C con los servicios web existentes y el uso de 1C como servicio web.
Al mismo tiempo, se entenderá por servicios web los sistemas que operan en Internet y que interactúan con ellos no solo a través de SOAP (que es exactamente un servicio web), sino también de otras formas, incluidas las solicitudes HTTP (S) ordinarias.
Riesgos de usar los servicios web de 1C
La implementación de servicios web apareció en la plataforma 1C81.
Pero su uso está plagado de riesgos:
- 1C8 no funciona bien sobre HTTPS, no hay herramientas de diagnóstico, por lo que a veces es imposible entender por qué, si un servicio tiene un certificado, no quiere funcionar a través de HTTPS. La salida es la implementación de servicios web a través de CURL o levantando un túnel HTTPS.
- 1C8 se adhiere a sus reglas para validar esquemas WSDL. A veces, por razones inexplicables, el esquema WSDL no quiere cargarse en el enlace WS. Puede averiguar el motivo solo en un foro de socios de un especialista. No hay herramientas de diagnóstico para el esquema WSDL, ni siquiera un motivo o una línea en la que se interrumpe la carga del esquema.
Reglas para construir servicios de ventas.
El cliente recibe un documento de venta (recibo) solo si la transacción del servicio fue exitosa. De lo contrario, es posible una situación en la que el cliente recibirá un cheque y estará seguro de que recibió el servicio, pero en realidad no es así.
Uso de servicios SOAP externos
Los servicios web SOAP utilizan esquemas WSDL y objetos XDTO para representar datos.
Descargar WSDL
Para utilizar un servicio externo, debe cargar su esquema WSDL.
Comprobación de la validez de un esquema WSDL
A veces, el esquema WSDL no se carga en 1C. Puede verificar la validez (corrección) del esquema con cualquier validador de esquema WSDL, por ejemplo, http://www.validwsdl.com/.
Debe cargar el esquema en algún sitio http (puede usar ftp) y especificar la dirección del archivo donde se carga el esquema:
Características de cargar WSDL en 1C
La peculiaridad de cargar WSDL en 1C es que es posible que no se carguen esquemas válidos. No hay un validador incorporado, por lo que debe buscar un error utilizando el método de análisis destructivo, reduciendo sucesivamente la cantidad de elementos en el esquema. Puede, por ejemplo, eliminar la descripción de un servicio web.
Procesamiento para probar un servicio web externo en ejecución
Para probar un servicio web externo en ejecución, utilice el procesamiento "TestArbitraryWebService.epf" del paquete de este artículo.
Las pruebas se pueden usar en el ejemplo del servicio Morpher que rechaza nombres (dirección del servicio http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):
De esta forma, puede probar cualquier servicio que tenga puntos de entrada simples que contengan parámetros tipos simples: número, fecha, cadena.
En el procesamiento, también puede especificar el nombre de usuario y la contraseña que se requieren para autorizar el acceso al servicio web.
Herramientas de depuración de servicios estándar
Para la depuración, puede usar el programa SoapUI, que puede enviar una solicitud arbitraria a un servicio web y recibir una respuesta de este.
SOAP y HTTPS
Desafortunadamente, SOAP en 1C se comporta de manera bastante caprichosa cuando se trabaja a través del protocolo HTTPS, la práctica muestra que es imposible lograr una conexión HTTPS, aunque la posibilidad está declarada en la plataforma. Faltan herramientas de diagnóstico y depuración para conocer los motivos por los que no se establece la conexión. Por lo tanto, es conveniente utilizar SOAP vía CURL.
El mecanismo incorporado para usar HTTPS implica que todos los certificados deben publicarse en un archivo pem común en el directorio del programa 1C.
Usando 1C como un servicio
Reglas para desarrollar un servicio basado en 1C
Operación "Hola"
Es una buena práctica crear una operación en el servicio que informe que el servicio está disponible. Esto facilita la vida de los integradores, les será más fácil comprobar si la conexión con el servicio está establecida.
Por ejemplo, puede utilizar la operación Hola sin parámetros, que simplemente devuelve el valor booleano True.
Publicación de un servicio web
El procedimiento está bien descrito en la documentación: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634:
La tarea de publicar servicios web es colocar los archivos de configuración *.1cws de los servicios web en el directorio apropiado del servidor web con la configuración adecuada para el servidor web. Para publicar servicios Web, debe ejecutar el comando de menú "Administración | Publicación de servicios web.
Este comando abrirá la ventana Publicación de servicios web.
La ventana Publicación de servicios web contiene la ruta al servidor web y dos listas:
- "Servicios web": una lista de servicios web de configuración;
- "Publicar": una lista de servicios web publicados en el servidor web especificado.
Utilice el botón "Conectar..." para especificar el servidor web en el que desea publicar los servicios web.
La ventana de selección de la ruta del servidor web le permite especificar la ruta de dos maneras:
- en la pestaña "Archivos": este método se utiliza cuando la publicación se realiza en la misma computadora donde está instalado el servidor web. La ruta especifica el directorio local correspondiente a la página de Internet desde la que se llamará al servidor web publicado;
- en la pestaña "Sitio FTP": este método se usa cuando desea publicar un servicio web en una computadora remota. Para realizar la publicación, debe especificar los parámetros de la conexión FTP con computadora remota y el directorio donde se publicará el servicio Web.
La publicación del servicio Web seleccionado se realiza mediante el botón "Publicar"
El botón Eliminar se utiliza para anular la publicación del servicio web.
Puede publicar en un directorio local o mediante FTP. También puede publicar en un servidor remoto a través de una ruta UNC si el servidor remoto es parte de la red local.
Después de la publicación, el servicio web está disponible en "http://localhost/test.1cws" o "http://xxx.ru/test.1cws", donde xxx.ru es la dirección del servidor remoto y localhost es el dirección típica del servidor local.
Autorización al servicio web 1C
Necesita estar autenticado para acceder al servicio.
Los problemas de autorización se tratan bien aquí: http://www.forum.mista.ru/topic.php?id=341168 y en el archivo de documentación:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81. htm
Por lo general, un servicio web se ejecuta bajo un usuario específico (más a menudo, uno especialmente creado). Puede "adjuntar" un usuario 1C mediante la autenticación de Windows al usuario IUSR_ de Windows (desactive la autorización 1C para el usuario). Alternativamente, puede borrar la lista de usuarios 1C, entonces no se requiere autorización.
Si se requieren varios usuarios, puede crear varios inicios de sesión para el servidor web, vincular un usuario de Windows a cada uno de ellos y, en consecuencia, registrar el acceso a los usuarios de Windows en 1C.
Las propiedades Usuario y Contraseña del objeto WSProxy no utilizan el inicio de sesión 1C, sino el inicio de sesión del usuario del servidor web.
Prueba de servicio web 1C
Para probar 1C como un servicio web, use el procesamiento "TestArbitraryWebService.epf", como se describe en la sección "Prueba de un servicio web externo que funcione".
El archivo 1cws es la descripción WSDL del servicio web 1C.
Uso de servicios en el comercio minorista
Por lo general, en el comercio minorista, los servicios se utilizan para brindar diversos servicios a la población: aceptar pagos, reembolsar préstamos, transferencias de dinero, comprar software etc.
Al mismo tiempo, se genera un recibo por el servicio prestado en 1C, en el que se almacenan los parámetros de la transacción. Después de eso, este cheque se imprime al cliente con información detallada sobre el servicio prestado. Es posible imprimir un cheque preliminar para que el cliente confirme los datos ingresados de sus palabras con su firma.
El servicio se puede integrar en un programa minorista escrito en el lenguaje 1C (UT, Retail y otros) de diferentes maneras:
- El procesamiento o el código se pueden escribir en lenguaje 1C, que hace todo el trabajo con el servicio.
- Se puede usar un programa que funcione con el servicio, y en 1C transmite solo información para romper cheques.
Organización de datos de servicio en 1C
Para almacenar información sobre la transacción en el recibo, debe crear una sección tabular adicional "Ventas complejas" con los siguientes detalles:
- Nomenclatura: vinculación a la nomenclatura del cheque.
- Parámetro: enlace al libro de referencia "Ventas complejas: Parámetros".
- Valor: valor del parámetro, tipo compuesto. La representación de cadena debe ser bastante larga (1024 caracteres) para ajustarse al texto de verificación.
El directorio "Ventas complejas: Parámetros" contiene una lista de parámetros de transacción.
Es más rentable usar la parte tabular que un conjunto de detalles, porque una transacción puede tener muchos de ellos, y en otros recibos no relacionados con el servicio, estos detalles no se utilizarán y ocuparán un espacio adicional. Además, dicha solución es universal para cualquier servicio y no requiere la reestructuración de datos después de la introducción de un nuevo servicio.
El vendedor recibe un marcador separado (o un formulario impreso, para no cambiar la configuración), en el que puede ver la tabla de detalles de la transacción del cheque.
Uso del procesamiento en lenguaje 1C
Considere el ejemplo del servicio condicional Paym para la configuración "Minorista".
- Entremos en 1C, un elemento predefinido del libro de referencia de nomenclatura "Paym". En modo 1C:Enterprise, después de actualizar la configuración, se le debe asignar el tipo de producto “Servicio”.
- En el procedimiento "Añadir nomenclatura en tab. parte" del módulo de formulario "Registro de ventas", llamamos al procesamiento de trabajar con el servicio, escrito en 1C. En caso de pago exitoso, anotamos y publicamos el cheque:
- El procesamiento debe imprimir un recibo previo (si es necesario), completar la parte tabular de las ventas complejas y preparar el texto para imprimir un recibo en el atributo predefinido "PaymReceiptText".
- En el procedimiento "Contabilización e impresión de un cheque" del módulo de cheques, reemplazamos el nombre del producto con el guardado en los detalles del cheque. Se reemplaza el texto solo para venta, para devoluciones solo se imprime el nombre del servicio, como de costumbre.
Una pregunta separada es cómo garantizar la finalización de la transacción. Aquellos. si la transacción tuvo lugar en el servicio, cómo asegurarse de que no se pierda en 1C. La forma más óptima es la conciliación de registros. Pero esto es objeto de una consideración aparte.
Uso de programas integrados con 1C
XDTO
A menudo, los servicios web usan XDTO. Aquí están los más consejos importantes y recetas para usar XDTO en 1C.
XDTO en plataforma 1C
Los paquetes XDTO descritos en la rama "Objetos XDTO" de la configuración están disponibles para crear tipos y objetos en la fábrica global XDTO Factory. Esto no es inmediatamente obvio.
Algunos tipos en el esquema no tienen nombre; debe pasar por la jerarquía de tipos para obtenerlos.
El ejemplo describía la lista del sistema, que contenía estructuras XDTO. Para crear la estructura en sí, fue necesario obtener su tipo de la siguiente manera:
Tipo = Factory.Type("urn:my.ru:MasterData:Business", "Business").Properties.Get("System").Type;
Problemas frecuentes con XDTO
Diferentes formatos de esquemas XSD
En algunos formatos, las etiquetas se denominan xs:, en algunos xsd:, pero 1C comprende ambos formatos con seguridad. Una vez hubo una situación en la que XSD normalmente se importaba a 1C sin errores, pero no creaba un solo paquete. La razón fue la ausencia de un atributo. targetNamespace en la etiqueta, respectivamente, 1C no sabía en qué paquete colocar el esquema, pero no dio errores.
Servicio de mantenimiento
Dado que el servicio es una combinación de dos sistemas: 1C y externo, los errores pueden estar en ambos sistemas, lo que reduce la confiabilidad general del trabajo.
Para facilitar la comprensión de las causas de las fallas en la operación de los servicios, se recomienda utilizar un conjunto de medidas.
Solicitud de registro
Enlaces
- XDTO
- Buena descripción de XDTO http://pro1c.org.ua/index.php?showtopic=214
- Interesantes servicios web gratuitos:
- Aeroflot - información de horarios de vuelos
- Morpher - declinación de nombres http://www.morpher.ru/WebServices/Morpher.aspx
- Sin montar:
- Instalación y uso de servicios web
- v8: ¿cómo cambiar el archivo de configuración de apache?
- v8: continuación del tema con los servicios web: no se puede conectar el servicio web
- v8: estoy rastreando los servicios web; no puedo crear un proxy...
- Libro de conocimientos: v8: Uso de servicios web externos en 1C:Enterprise 8;
- Instalación y uso de servicios web
Rara vez en estos días aplicación moderna hace sin API. Esto es cierto tanto para un sitio simple como para sistemas distribuidos altamente cargados. La prueba de API es una de las tareas principales en el proceso de garantía de calidad. No es sorprendente que la demanda de evaluadores que sepan cómo probar las API aumente día a día. En este curso, obtendrá una comprensión de los métodos, herramientas y enfoques en las pruebas de API, adquirirá los conocimientos necesarios, lo que sin duda tendrá un efecto positivo en su valor como especialista en pruebas.
Este curso será útil para los estudiantes familiarizados con los conceptos básicos de las pruebas de software que desean crecer más y mejorar sus habilidades.
Programa del curso:
Lección 1. Introductorio. Protocolo SOAP
- Brevemente sobre el disertante;
- Objetivos del Curso;
- ¿Qué es API, WS y por qué son necesarios?
- El papel de las pruebas API en el proceso de aseguramiento de la calidad;
- Descripción general de las herramientas de prueba de WS;
- Métodos utilizados en las pruebas de WS;
- La historia de SOAP;
- Terminología y conceptos principales (XML, XSD, Endpoint, WSDL).
Lección 2: Protocolo SOAP. arquitectura REST
- Terminología y conceptos principales (UDDI, XSLT, XPath, XQuery, métodos HTTP, estados HTTP);
- Estructura y componentes principales de SOAP;
- Ámbito de aplicación;
- Características del trabajo;
- Ventajas y desventajas;
- Características de la arquitectura REST;
- Terminología y conceptos principales (WADL, RESTful, JSON, JSONPath);
- principios DESCANSO;
- Código de estado y estados principales;
- verbos CRUD;
- Ventajas y desventajas.
Lección 3. Introducción a SoapUI. Trabajar con un proyecto REST
- instalación de Java;
- instalación de SoapUI;
- Descripción general de los elementos principales de la interfaz;
- Conexión del proyecto educativo;
- Revisión de métodos de proyecto;
- Enviar una solicitud y analizar la respuesta recibida;
- Examinar los servicios web disponibles del proyecto;
- Elaboración de un plan de prueba;
- Escritura de casos de prueba;
- Elementos “TestSuite”, “TestCase”, “TestSteps”.
Lección 4. Trabajar con proyecto REST (XML)
- Bloque "Afirmaciones";
- Ejecución de pruebas a diferentes niveles;
- Elemento “Propiedades”, características principales;
- Trabajando con Propiedades;
- Elemento “Transferencia de Propiedad”;
- Trabajar con aserciones
Lección 5. Trabajar con un proyecto REST (JSON)
- Condiciones y sucursales;
- Trabajando con Aserciones;
- TestRunner, características del trabajo;
- Ejecute TS, TC desde la línea de comandos;
- Trabajar con el corredor de prueba;
- Trabajando con guiones Groovy
Lección 6. Trabajar con guiones Groovy
- Trabajar con datos estáticos y dinámicos;
- Generamos datos de prueba;
- Obtenemos datos de “Propiedades”;
- Grabación y transferencia de datos;
- Condiciones y sucursales;
- Aserción de guión.
Lección 7. Características adicionales
- Conexión de bibliotecas externas y clases personalizadas;
- Servicios simulados;
- Por qué se necesitan servicios simulados;
- Un ejemplo de trabajo con un servicio simulado;
- Pero ¿qué pasa con CI?
- Instale Jenkins;
- Comenzando un proyecto en Jenkins.
SOAP (Protocolo simple de acceso a objetos) es un protocolo de paso de mensajes estandarizado entre un cliente y un servidor. Por lo general, se usa junto con HTTP(S), pero también puede funcionar con otros protocolos de capa de aplicación (como SMTP y FTP).
Probar SOAP en términos de técnicas de prueba no es fundamentalmente diferente de trabajar con otras API, pero requiere una preparación preliminar (en términos de teoría de protocolo) y herramientas de prueba especiales. En este artículo, me gustaría formular una pequeña lista de verificación de los conocimientos y habilidades necesarios que serán igualmente útiles tanto para un probador de SOAP (que a menudo no tiene una idea de "a qué aferrarse" después de establecer una tarea) como para un gerente que se ve obligado a evaluar el conocimiento de los probadores y desarrollar planes de aprendizaje.
Base teórica
El hecho de que SOAP sea un protocolo es de gran importancia para las pruebas: debe estudiar el protocolo en sí, los estándares y protocolos "primarios" en los que se basa y (si es necesario) las extensiones existentes.
XML
XML es un lenguaje de marcado similar a HTML. Cualquier mensaje enviado/recibido vía SOAP es un documento XML en el que los datos están convenientemente estructurados y fáciles de leer, por ejemplo:
¡No olvides escribir un artículo!
Puede obtener más información sobre XML en w3schools o codenet (en ruso). Asegúrese de prestar atención a la descripción de los espacios de nombres (un método para resolver conflictos al describir elementos en XML): en SOAP, su uso es necesario.
XSD
Cuando se trabaja, siempre es conveniente tener una descripción estandarizada de los posibles documentos XML y verificar que estén correctos en el llenado. Hay una definición de esquema XML (o XSD para abreviar) para esto. Las dos características principales de XSD para el probador son la descripción de los tipos de datos y la imposición de restricciones a los valores posibles. Por ejemplo, el elemento del ejemplo anterior puede hacerse opcional y limitarse a 255 caracteres usando XSD:
...
...
extensiones SOAP
En su trabajo, también puede encontrarse con varias "extensiones" de SOAP, estándares como WS-*. Uno de los más comunes es WS-Security, que permite trabajar con encriptación y firma electrónica. A menudo, se utiliza una WS-Policy con la que puede gestionar los derechos de uso de su servicio.
Un ejemplo del uso de WS-Security:
Todas estas extensiones son suficientes estructuras complejas, no se usa en todos los servicios SOAP; estudiarlos en detalle en la etapa inicial de dominio de las pruebas SOAP es poco probable que sea relevante.
Instrumentos
Como ya entendiste, SOAP es un asunto serio, para trabajar con él necesitas conocer la teoría y numerosos estándares. En la práctica, tal complejidad conduciría a costos laborales muy tangibles (por ejemplo, sería necesario mirar el esquema en un cuaderno cada vez y enviar solicitudes de curl). Por ello, se han creado herramientas para facilitar el trabajo con SOAP.
Editores XML/XSD
Un buen probador comienza a probar en la etapa de redacción de la documentación, por lo que es conveniente utilizar editores especiales para verificar los esquemas. Los dos más famosos son Oxygen (multiplataforma) y Altova (solo Windows); ambos son pagados. Estos son programas muy poderosos que los analistas usan activamente cuando describen servicios.
En mi práctica, tres características de los editores resultaron útiles: visualización XSD, generación de XML basada en XSD y validación de XML en XSD.
1. Visualización XSD necesario para una representación visual del esquema, lo que le permite aislar rápidamente los elementos y atributos requeridos, así como las restricciones existentes. Por ejemplo, para una solicitud CheckTextRequest, el elemento de texto es obligatorio y los tres atributos son opcionales (con el atributo de opciones establecido en el valor predeterminado de cero).
La visualización es necesaria cuando hay muchos tipos y restricciones en el esquema. Si solo lo necesita y no quiere pagar por editores dedicados, puede considerar alternativas gratuitas (como JDeveloper).
2. Generación XML basada en XSDútil cuando desea ver un ejemplo válido de un mensaje. Lo uso para experimentar rápidamente con la posible finalización del mensaje y verificar los matices de cómo funcionan las restricciones.
3. Después de usar la característica del punto 2, es útil Validación XML contra XSD- es decir, verifique que el mensaje sea correcto. Juntas, las funciones 2 y 3 le permiten detectar defectos complicados en XSD incluso cuando el servicio en sí está en desarrollo.
Herramienta de prueba - SoapUI
Las pruebas de SOAP casi siempre implican el uso de SoapUI. Puede leer sobre el uso de esta herramienta en varias fuentes (,), pero será más efectivo leer la documentación oficial. Distingo 8 niveles condicionales de dominio de SoapUI:
Nivel 1 - Puedo enviar solicitudes
Aprenda a crear un proyecto basado en WSDL. SoapUI puede generar todas las solicitudes necesarias para usted; solo tiene que verificar la corrección de su llenado y hacer clic en el botón "Enviar". Una vez que haya dominado el arte de hacer consultas válidas, debe dominar el arte de hacer consultas no válidas, provocando la aparición errores
Nivel 2 - Puedo hacer Test Suites y Test Cases
Comience a hacer mini-autotests. Los conjuntos de pruebas y los casos de prueba le permiten crear scripts de prueba de API, preparar datos para solicitudes y comparar automáticamente la respuesta recibida con la esperada. Al principio, se pueden usar simplemente como colecciones de consultas. Por ejemplo, si tiene un defecto y desea verificarlo rápidamente después de corregirlo, puede asignar un conjunto de pruebas separado específicamente para las solicitudes de defectos.
Nivel 3: puede escribir afirmaciones
Después de dominar los casos de prueba, le será útil aprender cómo hacerlos verificables automáticamente. Después de eso, ya no necesitarás buscar información sobre la respuesta con tus “ojos”: si hay una verificación automática, los casos se marcarán en verde (si se pasa la verificación) o en rojo (si no se pasa) . SoapUI proporciona un gran conjunto de posibles comprobaciones (afirmaciones), pero las más cómodas y sencillas son Contiene y No contiene. Con su ayuda, puede verificar la presencia de un texto en particular en la respuesta recibida. Estas comprobaciones también admiten búsquedas de expresiones regulares.
Nivel 4: uso de XPath y/o XQuery en aserciones
Para aquellos que están un poco familiarizados con la interfaz de usuario que usa Selenium, el lenguaje XPath es algo familiar. En términos generales, XPath le permite buscar elementos en un documento XML. XQuery es una tecnología similar que puede usar XPath internamente; este lenguaje es mucho más potente, se parece a SQL. Ambos lenguajes se pueden usar en Aserciones. Los controles con su ayuda son más específicos y estables, por lo que sus casos serán más creíbles.
Nivel 5: puede escribir pruebas complejas usando pasos especiales
Los casos de prueba pueden contener no solo una solicitud, sino también varias (por ejemplo, cuando desea emular un escenario de usuario estándar "crear una entidad" → "exportar una entidad"). Puede haber otros pasos especiales entre las solicitudes, como:
- Propiedades y transferencia de propiedad (ayuda a reutilizar datos y transferirlos entre solicitudes);
- Solicitud JDBC (utilizada para obtener datos de la base de datos);
- Goto condicional (le permite hacer bifurcaciones o bucles en un caso de prueba);
- Ejecute TestCase (ayuda a poner algunas consultas típicas en casos de prueba separados y llamarlos donde sea necesario).
Nivel 6: uso de scripts Groovy
SoapUI le permite escribir scripts Groovy en varios lugares. El caso más simple es generar datos en la consulta misma usando inserciones de $(=). Yo uso estos complementos todo el tiempo:
- $(=nueva Fecha().format("aaaa-MM-dd'T'HH:mm:ss"))– para insertar la fecha y hora actual en el formato requerido;
- $(=java.util.UUID.aleatorioUUID())– para insertar un GUID aleatorio bien formado.
Los guiones completos se pueden utilizar como pasos en casos y pruebas. En algún momento, encontrará que varios pasos especiales del quinto nivel pueden reemplazarse con un guión a la vez.
Nivel 7: uso de MockServices
SoapUI basado en WSDL puede generar objetos simulados. Un objeto simulado es la simulación más simple de un servicio. Con la ayuda de "simulacros", puede comenzar a escribir y depurar casos de prueba incluso antes de que el servicio esté realmente disponible para la prueba. También se pueden usar como "talones" para servicios que no están disponibles temporalmente.
Nivel 8 - dios SoapUI
¿Sabes la diferencia entre pagado y versiones gratuitas SoapUI y use la API de SoapUI en el código. Utiliza complementos y ejecuta casos a través de la línea de comando y/o CI. Sus casos de prueba son simples y fáciles de mantener. En general, "te comiste al perro" en este instrumento. Me encantaría hablar con alguien que domine SoapUI a este nivel. Si es así, ¡por favor deje un comentario!
Pruebas con lenguajes de programación
Daré un ejemplo de cómo se ve una solicitud a la API de YandexSpeller, realizada con groovy-wslite:
importar wslite.soap.*
def cliente = nuevo SOAPClient("http://speller.yandex.net/services/spellservice?WSDL")
def respuesta = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
cuerpo (
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
texto("error")
}
}
}
afirmar "error" == respuesta.CheckTextResponse.SpellResult.error.s.text()
afirmar "1" == [correo electrónico protegido]()
Hasta donde yo sé, todavía no existen marcos de trabajo de alto nivel (como Rest-assured) para las pruebas de SOAP, pero recientemente apareció una herramienta interesante: karate. Con él, puede describir casos para probar SOAP y REST en forma de escenarios como Cucumber / Gherkin. Para muchos probadores, la referencia al kárate será solución ideal, porque tales escenarios, en términos de la complejidad de la escritura y los casos de soporte, estarán en algún punto intermedio entre el uso de SoapUI y la escritura de su propio marco de pruebas de SOAP.
Conclusión
Es poco probable que alguna vez quiera probar SOAP así, por sí mismo (como podría hacerlo con REST). Este es un protocolo pesado que se utiliza en soluciones empresariales serias. Pero su peso es al mismo tiempo un regalo para el probador: todas las tecnologías utilizadas están estandarizadas, hay herramientas de trabajo de alta calidad. Todo lo que se requiere del probador es el deseo de estudiarlos y usarlos.
Preparemos la misma lista de verificación de las habilidades necesarias para un probador. Entonces, si recién está comenzando a probar los servicios SOAP, necesita saber y poder usar:
- wsdl.
- JABÓN.
- Editores XML/XSD (a nivel de visualización XSD).
- SoapUI en el nivel 1.
Como puede ver, el enfoque principal está en los estándares de aprendizaje, en SoapUI es suficiente solo para poder ejecutar solicitudes. A medida que se sumerja en las pruebas de SOAP, se enfrentará a tareas que requerirán habilidades y conocimientos más serios, pero no debe intentar aprender todo de una vez. Mucho más importante es la consistencia en aumentar el nivel de complejidad de las tareas realizadas. Siguiendo esta recomendación, un día te darás cuenta de que te has convertido un buen especialista¡en esta región!
