API orientadas a datos data-oriented-apis

Las API orientadas a datos le permiten abordar todo el modelo de datos.

Descripción general del modelo de datos overview-of-the-datamodel

Adobe Campaign no ofrece una API de lectura dedicada por entidad (sin función getRecipient o getDelivery, etc.). Utilice los métodos de lectura y modificación de datos QUERY & WRITER para acceder a los datos del modelo.

Adobe Campaign permite administrar colecciones: las consultas permiten recuperar un conjunto de información recopilada en la base. A diferencia del acceso en modo SQL, las API de Adobe Campaign devuelven un árbol XML en lugar de columnas de datos. Por lo tanto, Adobe Campaign crea documentos compuestos con todos los datos recopilados.

Este modo operativo no ofrece una asignación uno a uno entre los atributos y elementos de los documentos XML y las columnas de las tablas de la base de datos.

Los documentos XML se almacenan en campos de tipo MEMO de la base de datos.

Descripción del modelo description-of-the-model

Debe estar familiarizado con el modelo de datos de Adobe Campaign para poder abordar los campos de la base de datos en los scripts.

Para ver una presentación del modelo de datos, consulte la Descripción del modelo de datos de Adobe Campaign.

Query y Writer query-and-writer

El siguiente esquema de introducción detalla los intercambios de bajo nivel para leer (ExecuteQuery) y escribir (Writer) entre la base de datos y el cliente (páginas web o consola de cliente de Adobe Campaign).

ExecuteQuery executequery

Para las columnas y condiciones, puede utilizar Consultas.

Esto permite aislar el SQL subyacente. El idioma de la consulta no depende del motor subyacente: algunas funciones se reasignarán, lo que puede generar varios pedidos SQL SELECT.

Para obtener más información, consulte Ejemplo del método "ExecuteQuery" del esquema "xtk:queryDef".

El ExecuteQuery El método se presenta en ExecuteQuery (xtk:queryDef).

Escribir write

Los comandos Write permiten escribir documentos simples o complejos, con entradas en una o varias tablas de la base.

Las API transaccionales permiten administrar las conciliaciones a través de la updateOrInsert command: un comando permite crear o actualizar datos. También puede configurar la combinación de modificaciones (fusionar): este modo operativo permite autorizar actualizaciones parciales.

La estructura XML ofrece una vista lógica de los datos y permite evitar la estructura física de la tabla SQL.

El método Write se presenta en Write/WriteCollection (xtk:session).

ExecuteQuery (xtk:queryDef) executequery--xtk-querydef-

Este método permite realizar consultas a partir de datos asociados a un esquema. Se necesita una cadena de autenticación (debe estar conectado) y un documento XML que describa la consulta que se va a enviar como parámetros. El parámetro return es un documento XML que contiene el resultado de la consulta en el formato del esquema al que hace referencia la consulta.

Definición del método "ExecuteQuery" en el esquema "xtk:queryDef":

<method name="ExecuteQuery" const="true">
  <parameters>
    <param desc="Output XML document" name="output" type="DOMDocument" inout="out"/>
  </parameters>
</method>

Formato del documento XML de la consulta de entrada format-of-the-xml-document-of-the-input-query

La estructura del documento XML de la consulta se describe en el esquema "xtk:queryDef". Este documento describe las cláusulas de una consulta SQL: "select", "where", "order by", "group by", "having".

<queryDef schema="schema_key" operation="operation_type">
  <select>
    <node expr="expression1">
    <node expr="expression2">
    ...
  </select>
  <where>
    <condition expr="expression1"/>
    <condition expr="expression2"/>
    ...
  </where>
  <orderBy>
    <node expr="expression1">
    <node expr="expression2">
    ...
  </orderBy>
  <groupBy>
    <node expr="expression1">
    <node expr="expression2">
    ...
  </groupBy>
  <having>
    <condition expr="expression1"/>
    <condition expr="expression2"/>
    ...
  </having>
</queryDef>

Una subconsulta ( <subquery> ) se puede definir en una <condition> Elemento. La sintaxis de un <subquery> se basa en la sintaxis de un <querydef>.

Ejemplo de un <subquery> : </subquery>

<condition setOperator="NOT IN" expr="@id" enabledIf="$(/ignored/@ownerType)=1">
  <subQuery schema="xtk:operatorGroup">
     <select>
       <node expr="[@operator-id]" />
     </select>
     <where>
       <condition expr="[@group-id]=$long(../@owner-id)"/>
     </where>
   </subQuery>
</condition>

Una consulta debe hacer referencia a un esquema de inicio desde el esquema atributo.

El tipo de operación deseado se introduce en la variable operación y contiene uno de los siguientes valores:

El XPath La sintaxis se utiliza para localizar datos basados en el esquema de entrada. Para obtener más información sobre XPath, consulte Esquemas de datos.

Ejemplo con la operación "get" example-with-the--get--operation

Recupera los apellidos y el nombre de un destinatario (esquema "nms:recipient") con un filtro en el correo electrónico.

<queryDef schema="nms:recipient" operation="get">
  <!-- fields to retrieve -->
  <select>
    <node expr="@firstName"/>
    <node expr="@lastName"/>
  </select>

  <!-- condition on email -->
  <where>
    <condition expr="@email= 'john.doe@aol.com'"/>
  </where>
</queryDef>

Ejemplo con la operación "select" example-with-the--select--operation

Devuelve la lista de destinatarios filtrados en una carpeta y el dominio de correo electrónico con un orden descendente en la fecha de nacimiento.

<queryDef schema="nms:recipient" operation="select">
  <select>
    <node expr="@email"/>
    <!-- builds a string with the concatenation of the last name and first name separated by a dash -->
    <node expr="@lastName+'-'+@firstName"/>
    <!-- get year of birth date -->
    <node expr="Year(@birthDate)"/>
  </select>

  <where>
     <condition expr="[@folder-id] = 1234 and @domain like 'Adobe%'"/>
  </where>

  <!-- order by birth date -->
  <orderBy>
    <node expr="@birthDate" sortDesc="true"/> <!-- by default sortDesc="false" -->
  </orderBy>
</queryDef>

Las expresiones pueden ser campos simples o expresiones complejas, como operaciones aritméticas o la concatenación de cadenas.

Para limitar el número de registros que se van a devolver, agregue lineCount atribuir a <querydef> Elemento.

Para limitar a 100 el número de registros que devuelve la consulta:

<queryDef schema="nms:recipient" operation="select" lineCount="100">
...

Para recuperar los siguientes 100 registros, ejecute de nuevo la misma consulta y agregue startLine atributo.

<queryDef schema="nms:recipient" operation="select" lineCount="100" startLine="100">
...

Ejemplo con la operación "count" example-with-the--count--operation

Para contar el número de registros de una consulta:

<queryDef schema="nms:recipient" operation="count"">
  <!-- condition on the folder and domain of the email -->
  <where>
    <condition expr="[@folder-id] = 1234" and @domain like 'Adobe%'"/>
  </where>
</queryDef>

Agrupación de datos data-grouping

Para recuperar direcciones de correo electrónico a las que se hace referencia más de una vez:

<queryDef schema="nms:recipient" operation="select">
  <select>
    <node expr="@email"/>
    <node expr="count(@email)"/>
  </select>

  <!-- email grouping clause -->
  <groupby>
    <node expr="@email"/>
  </groupby>

  <!-- grouping condition -->
  <having>
    <condition expr="count(@email) > 1"/>
  </having>

</queryDef>

La consulta se puede simplificar añadiendo la variable groupBy atribuir directamente al campo que se va a agrupar:

<select>
  <node expr="@email" groupBy="true"/>
</select>

Colocación de corchetes en condiciones bracketing-in-conditions

Estos son dos ejemplos de creación de corchetes en la misma condición.

Es posible reemplazar el operador "OR" con la operación "IN" cuando se aplican varias condiciones al mismo campo:

<where>
  <condition>
    <condition expr="@age IN (15, 45)"/>
    <condition expr="@city IN ('Newton', 'Culver City')"/>
  </condition>
</where>

Esta sintaxis simplifica la consulta cuando se utilizan más de dos datos en la condición.

Ejemplos de vínculos examples-on-links

Enlazar los parámetros de las cláusulas "where" y "select" binding-the-parameters-of-the--where--and--select--clause

El enlace de parámetros permite que el motor establezca los valores de los parámetros utilizados en la consulta. Esto resulta muy útil, ya que el motor se encarga del escape de valores y existe la ventaja adicional de una caché para los parámetros que se van a recuperar.

Cuando se construye una consulta, los valores "enlazados" se sustituyen por un carácter (? en ODBC, #[index]# en postgres…) en el cuerpo de la consulta SQL.

<select>
  <!--the value will be bound by the engine -->
  <node expr="@startDate = #2002/02/01#"/>
  <!-- the value will not be bound by the engine but visible directly in the query -->
  <node expr="@startDate = #2002/02/01#" noSqlBind="true"/>
</select>

Para evitar enlazar un parámetro, el atributo "noSqlBind" debe rellenarse con el valor "true".

Sugerencia para la creación de consultas: query-building-tip-

Para ayudar con la sintaxis de una consulta, puede escribirla utilizando el editor de consultas genérico en la consola del cliente de Adobe Campaign ( Tools/ Generic query editor… menú). Para ello, haga lo siguiente:

Formato del documento de salida output-document-format

El parámetro de retorno es un documento XML con el formato del esquema asociado a la consulta.

Ejemplo de una devolución desde el esquema "nms:recipient" en una operación "get":

<recipient email="john.doe@adobe.com" lastName"Doe" firstName="John"/>

En una operación "select", el documento devuelto es una enumeración de elementos:

<!-- the name of the first element does not matter -->
<recipient-collection>
  <recipient email="john.doe@adobe.com" lastName"Doe" firstName="John"/>
  <recipient email="peter.martinez@adobe.com" lastName"Martinez" firstName="Peter"/>
  <recipient...
</recipient-collection>

Ejemplo de documento devuelto para la operación de tipo "recuento":

<recipient count="3"/>

Alias alias

Un alias permite modificar la ubicación de los datos en el documento de salida. El alias debe especificar un XPath en el campo correspondiente.

<queryDef schema="nms:recipient" operation="get">
  <select>
    <node expr="@firstName" alias="@firstName"/>
    <node expr="@lastName"/>
    <node expr="[folder/@label]" alias="@My_folder"/>
  </select>
</queryDef>

Devuelve:

<recipient My_folder="Recipients" First name ="John" lastName="Doe"/>

En lugar de:

<recipient firstName="John" lastName="Doe">
  <folder label="Recipients"/>
</recipient>

Ejemplo de mensajes SOAP example-of-soap-messages

Write/WriteCollection (xtk:session) write---writecollection--xtk-session-

Estos servicios se utilizan para insertar, actualizar o eliminar una entidad (método "Write") o una colección de entidades (método "WriteCollection").

Las entidades que se van a actualizar están asociadas a un esquema de datos. Los parámetros de entrada son una cadena de autenticación (debe iniciar sesión) y un documento XML que contiene los datos que se van a actualizar.

Este documento se complementa con instrucciones para configurar los procedimientos de escritura.

La llamada no devuelve ningún dato, excepto errores.

Definición de los métodos "Write" y "WriteCollection" en el esquema "xtk:session":

<method name="Write" static="true">
  <parameters>
    <param name="doc" type="DOMDocument" desc="Difference document"/>
  </parameters>
</method>
<method name="WriteCollection" static="true">
  <parameters>
    <param name="doc" type="DOMDocument" desc="Difference collection document"/>
  </parameters>
</method>

Información general overview

La reconciliación de datos funciona en función de la definición de las claves introducidas en el esquema asociado. El procedimiento de escritura busca la primera clave elegible en función de los datos introducidos en el documento de entrada. La entidad se inserta o actualiza en función de su existencia en la base de datos.

La clave del esquema de la entidad que se va a actualizar se completa en función del xtkschema atributo.

Por lo tanto, la clave de reconciliación se puede forzar con el _key que contiene la lista de XPath que componen la clave (separados por comas).

Es posible forzar el tipo de operación rellenando el campo _operation con los siguientes valores:

Ejemplo con el método "Write" example-with-the--write--method

Actualización o inserción de un destinatario (operación "insertOrUpdate" implícita) con dirección de correo electrónico, fecha de nacimiento y ciudad:

<recipient xtkschema="nms:recipient" email="john.doe@adobe.com" birthDate="1956/05/04" folder-id=1203 _key="@email, [@folder-id]">
  <location city="Newton"/>
</recipient>

Eliminación de un destinatario:

<recipient xtkschema="nms:recipient" _operation="delete" email="rene.dupont@adobe.com" folder-id=1203 _key="@email, [@folder-id]"/>

Ejemplo con el método "WriteCollection" example-with-the--writecollection--method

Actualización o inserción para varios destinatarios:

<recipient-collection xtkschema="nms:recipient">
  <recipient email="john.doe@adobe.com" firstName="John" lastName="Doe" _key="@email"/>
  <recipient email="peter.martinez@adobe.com" firstName="Peter" lastName="Martinez" _key="@email"/>
  <recipient ...
</recipient-collection>

Ejemplo sobre vínculos example-on-links

Ejemplo 1 example-1

Asociar la carpeta con un destinatario en función de su nombre interno (@name).

<recipient _key="[folder/@name], @email" email="john.doe@adobe.net" lastName="Doe" firstName="John" xtkschema="nms:recipient">
  <folder name="Folder2" _operation="none"/>
</recipient>

Los atributos "_key" y "_operation" se pueden introducir en un elemento enlazado. El comportamiento en este elemento es el mismo que en el elemento principal del esquema de entrada.

La definición de la clave de la entidad principal ("nms:recipient") consiste en un campo de una tabla vinculada (elemento <folder> esquema "xtk:folder") y el correo electrónico.

Ejemplo 2 example-2

Actualización de la empresa (tabla vinculada en el esquema "cus:company") desde un destinatario:

<recipient _key="[folder/@name], @email" email="john.doe@adobe.net" lastName="Doe" firstName="John" xtkschema="nms:recipient">
  <company name="adobe" code="ERT12T" _key="@name" _operation="update"/>
</recipient>

Ejemplo 3 example-3

Añadir un destinatario a un grupo con la tabla de relación de grupos ("nms:rcpGrpRel"):

<recipient _key="@email" email="martin.ledger@adobe.net" xtkschema="nms:recipient">
  <rcpGrpRel _key="[rcpGroup/@name]">
    <rcpGroup name="GRP1"/>
  </rcpGrpRel>
</recipient>

Elementos de colección XML xml-collection-elements

De forma predeterminada, todos los elementos de colección deben rellenarse para actualizar los elementos de colección XML. Los datos de la base de datos se reemplazarán con los datos del documento de entrada. Si el documento contiene solo los elementos que se van a actualizar, debe rellenar el atributo "_operation" en todos los elementos de recopilación que se van a actualizar para forzar una combinación con los datos XML de la base de datos.

Ejemplo de mensajes SOAP example-of-soap-messages-1