Tenemos un empleado cuyo apellido es Nulo. Nuestra aplicación de búsqueda de empleados se anula cuando se usa ese apellido como término de búsqueda (que ahora es bastante frecuente). El error recibido (¡gracias Fiddler!) Es:

<soapenv:Fault>
   <faultcode>soapenv:Server.userException</faultcode>
   <faultstring>coldfusion.xml.rpc.CFCInvocationException: [coldfusion.runtime.MissingArgumentException : The SEARCHSTRING parameter to the getFacultyNames function is required but was not passed in.]</faultstring>

Lindo, ¿eh?

El tipo de parámetro es string.

Estoy usando:

• WSDL ( SOAP )
• Flex 3.5
• ActionScript 3
• ColdFusion 8

Tenga en cuenta que el error no se produce al llamar al servicio web como un objeto desde una página de ColdFusion.

Rastreándolo

Al principio pensé que se trataba de un error de coerción en el que se nullestaba coaccionando "null"y "null" == nullestaba pasando una prueba . No es. Estaba cerca, pero muy, muy mal. ¡Lo siento por eso!

Desde entonces, he jugado mucho en wonderfl.net y he rastreado el código enmx.rpc.xml.* . En la línea 1795 de XMLEncoder(en la fuente 3.5), en setValue, todo el XMLEncoding se reduce a

currentChild.appendChild(xmlSpecialCharsFilter(Object(value)));

que es esencialmente lo mismo que:

currentChild.appendChild("null");

Este código, de acuerdo con mi violín original, devuelve un elemento XML vacío. ¿Pero por qué?

Porque

Según el comentarista Justin Mclean en el informe de error FLEX-33664 , el siguiente es el culpable (vea las dos últimas pruebas en mi violín que verifican esto):

var thisIsNotNull:XML = <root>null</root>;
if(thisIsNotNull == null){
    // always branches here, as (thisIsNotNull == null) strangely returns true
    // despite the fact that thisIsNotNull is a valid instance of type XML
}

Cuando currentChild.appendChildse pasa la cadena "null", primero la convierte en un elemento XML raíz con texto null, y luego prueba ese elemento contra el literal nulo. Esta es una prueba de igualdad débil, por lo que el XML que contiene nulo se coacciona al tipo nulo o el tipo nulo se coacciona a un elemento xml raíz que contiene la cadena "nulo", y la prueba pasa donde posiblemente podría fallar. Una solución podría ser usar siempre pruebas de igualdad estrictas al verificar XML (o cualquier cosa, realmente) para "nulidad".

Solución

Los valores CDATA son la forma más apropiada de mutar un valor de texto completo que de otra forma causaría problemas de codificación / decodificación. La codificación hexadecimal, por ejemplo, está destinada a caracteres individuales. Se prefieren los valores CDATA cuando se escapa del texto completo de un elemento. La razón principal de esto es que mantiene la legibilidad humana.

En la nota xkcd , el sitio web de Bobby Tables tiene buenos consejos para evitar la interpretación incorrecta de los datos del usuario (en este caso, la cadena "Nulo") en consultas SQL en varios idiomas, incluido ColdFusion .

No queda claro a partir de la pregunta que esta es la fuente del problema, y ​​dada la solución anotada en un comentario a la primera respuesta (incrustando los parámetros en una estructura) parece probable que se tratara de otra cosa.

El problema podría estar en el codificador SOAP de Flex. Intente extender el codificador SOAP en su aplicación Flex y depure el programa para ver cómo se maneja el valor nulo.

Supongo que se pasa como NaN (no es un número). Esto estropeará el proceso de desorganización de mensajes SOAP en algún momento (más notablemente en el servidor JBoss 5 ...). Recuerdo extender el codificador SOAP y realizar una comprobación explícita de cómo se maneja NaN.

@ doc_180 tenía el concepto correcto, excepto que está enfocado en los números, mientras que el póster original tenía problemas con las cadenas.

La solución es cambiar el mx.rpc.xml.XMLEncoderarchivo. Esta es la línea 121:

    if (content != null)
        result += content;

(Miré el SDK de Flex 4.5.1; los números de línea pueden diferir en otras versiones).

Básicamente, la validación falla porque 'el contenido es nulo' y, por lo tanto, su argumento no se agrega al paquete SOAP saliente; causando así el error de parámetro faltante.

Tiene que extender esta clase para eliminar la validación. Luego hay una gran bola de nieve en la cadena, modificando SOAPEncoder para usar su XMLEncoder modificado, y luego modificando Operation para usar su SOAPEncoder modificado, y luego moidfying WebService para usar su clase de Operación alternativa.

Pasé unas horas en eso, pero necesito seguir adelante. Probablemente tomará uno o dos días.

Es posible que pueda arreglar la línea XMLEncoder y hacer algunos parches de mono para usar su propia clase.

También agregaré que si cambia a usar RemoteObject / AMF con ColdFusion, el valor nulo se pasa sin problemas.

11/16/2013 actualización :

Tengo una adición más reciente a mi último comentario sobre RemoteObject / AMF. Si está utilizando ColdFusion 10; entonces las propiedades con un valor nulo en un objeto se eliminan del objeto del lado del servidor. Por lo tanto, debe verificar la existencia de propiedades antes de acceder a ella o obtendrá un error de tiempo de ejecución.

Comprueba así:

<cfif (structKeyExists(arguments.myObject,'propertyName')>
 <!--- no property code --->
<cfelse>
 <!--- handle property  normally --->
</cfif>

Este es un cambio de comportamiento de ColdFusion 9; donde las propiedades nulas se convertirían en cadenas vacías.

Editar 06/12/2013

Como había una pregunta sobre cómo se tratan los nulos, aquí hay una aplicación de muestra rápida para demostrar cómo una cadena "nulo" se relacionará con la palabra reservada nulo.

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
               xmlns:s="library://ns.adobe.com/flex/spark"
               xmlns:mx="library://ns.adobe.com/flex/mx" minWidth="955" minHeight="600" initialize="application1_initializeHandler(event)">
    <fx:Script>
        <![CDATA[
            import mx.events.FlexEvent;

            protected function application1_initializeHandler(event:FlexEvent):void
            {
                var s :String = "null";
                if(s != null){
                    trace('null string is not equal to null reserved word using the != condition');
                } else {
                    trace('null string is equal to null reserved word using the != condition');
                }

                if(s == null){
                    trace('null string is equal to null reserved word using the == condition');
                } else {
                    trace('null string is not equal to null reserved word using the == condition');
                }

                if(s === null){
                    trace('null string is equal to null reserved word using the === condition');
                } else {
                    trace('null string is not equal to null reserved word using the === condition');
                }
            }
        ]]>
    </fx:Script>
    <fx:Declarations>
        <!-- Place non-visual elements (e.g., services, value objects) here -->
    </fx:Declarations>
</s:Application>

La salida de rastreo es:

la cadena nula no es igual a la palabra reservada nula usando la condición! =

la cadena nula no es igual a la palabra reservada nula usando la condición ==

la cadena nula no es igual a la palabra reservada nula usando la condición ===

Traduce todos los caracteres a sus equivalentes de entidad hexadecimal. En este caso, Nullse convertiría en&#4E;K&#6C;&#6C;

La cadena de un nullvalor en ActionScript dará la cadena "NULL". Mi sospecha es que alguien ha decidido que es, por lo tanto, una buena idea decodificar la cadena , "NULL"ya que nullcausa la rotura que ves aquí, probablemente porque estaban pasando nullobjetos y obteniendo cadenas en la base de datos, cuando no querían eso (así que asegúrese de verificar ese tipo de error también).

Como truco, podría considerar tener un manejo especial en el lado del cliente, convirtiendo la cadena 'Nulo' en algo que nunca ocurrirá, por ejemplo, XXNULLXX y volviendo a convertir en el servidor.

No es bonito, pero puede resolver el problema para tal caso límite.

Bueno, supongo que la implementación de Flex del codificador SOAP parece serializar valores nulos incorrectamente. Serializarlos como String Null no parece ser una buena solución. La versión formalmente correcta parece ser pasar un valor nulo como:

<childtag2 xsi:nil="true" />

Por lo tanto, el valor de "Nulo" no sería más que una cadena válida, que es exactamente lo que está buscando.

Supongo que solucionar esto en Apache Flex no debería ser tan difícil de hacer. Recomendaría abrir un problema de Jira o contactar a los chicos de la lista de correo apache-flex. Sin embargo, esto solo solucionaría el lado del cliente. No puedo decir si ColdFusion podrá trabajar con valores nulos codificados de esta manera.

Consulte también la publicación de blog de Radu Cotescu Cómo enviar valores nulos en solicitudes de soapUI .

Es un error, pero suponiendo que haya una longitud mínima para SEARCHSTRING, por ejemplo, 2 caracteres, substringel SEARCHSTRINGparámetro en el segundo carácter y pasarlo como dos parámetros en su lugar: SEARCHSTRING1 ("Nu")y SEARCHSTRING2 ("ll"). Concatenatevolver a unirlos al ejecutar la consulta a la base de datos.