Manual del Participante

SAP Data Services 4.2

Designer
Tabla de contenido
Capítulo 1 – Abriendo Data Services Designer.............................................................................3
Capítulo 2 – Objetos.....................................................................................................................3
Reutilizables.............................................................................................................................3
De un solo uso..........................................................................................................................3
Capítulo 3 – Proyectos.................................................................................................................4
Capítulo 4 – Jobs..........................................................................................................................4
Capítulo 5 – Datastores................................................................................................................5
Capítulo 6 – File Formats..............................................................................................................5
Capítulo 7 – File Location Objects................................................................................................6
Capítulo 8 – Dataflows.................................................................................................................7
Capítulo 9 – Platform Transforms.................................................................................................8
Capítulo 10 – Workflows..............................................................................................................8
Capítulo 11 – Conditionals...........................................................................................................9
Capítulo 12 – While Loops............................................................................................................9
Capítulo 13 – Try-Catch..............................................................................................................10
Capitulo 14 – Scripts...................................................................................................................10
Capítulo 15 – Real time Jobs......................................................................................................11
Sugerencias de Diseño...........................................................................................................11
Capítulo 16 – Embedded Dataflows...........................................................................................12
Capitulo 17 – Substitution Parameters.......................................................................................12
Capítulo 18 – System Configurations..........................................................................................13
Capítulo 1 – Iniciando Data Services Designer
Debe tener acceso a un repositorio local para iniciar sesión en el software. Normalmente, se crea un
repositorio durante la instalación. Cada repositorio debe estar asociado al menos a un Job Server antes
de poder ejecutar Jobs desde el Designer.

1 – Abrir el acceso directo

2 – Ingresar las Credenciales recibidas, el Job Server al cual nos queremos conectar
3 – Elegir el repositorio asignado
4 – OK para ingresar a la herramienta

Capítulo 2 – Objetos
Todas las "entidades" que defina, edite o con las que trabaje en Designer, se denominan objetos.
El Local Object Library muestra objetos como Metadata de origen y destino, funciones, proyectos y Jobs

Los objetos son jerárquicos y consisten en:

 Opciones, que controlan el funcionamiento de los objetos. Por ejemplo, en un Datastore, el

nombre de la base de datos a la que se conecta es una opción para el objeto Datastore.

 Propiedades, que documentan el objeto. Por ejemplo, el nombre del objeto y la fecha en que
se creó son propiedades. Las propiedades describen un objeto, pero no afectan a su
funcionamiento.

El software tiene dos tipos de objetos:

Reutilizables
Puede reutilizar y replicar la mayoría de los objetos definidos en la aplicación. Después de definir y
guardar un objeto reutilizable, DS almacena la definición en el repositorio local. A continuación, puede
reutilizar la definición tantas veces como sea necesario creando llamadas a esa definición. Acceda a
objetos reutilizables a través de la Local Object Library.

Un objeto reutilizable tiene una sola definición; todas las llamadas al objeto hacen referencia a esa
definición. Si cambia la definición del objeto en un lugar, está cambiando el objeto en todos los demás
lugares en los que aparece.

Un Dataflow, por ejemplo, es un objeto reutilizable. Varios Jobs, como un Job de carga semanal y un Job
de carga diaria, pueden llamar al mismo Dataflow. Si el Dataflow cambia, ambos Jobs utilizan la nueva
versión Dataflow.

La Local Object Library contiene definiciones de objetos. Al arrastrar e insertar un objeto, realmente está
creando una nueva referencia (o llamada) a la definición de objeto existente.

De un solo uso
Los objetos de un solo uso sólo aparecen como componentes de otros objetos y sólo funcionan en el
contexto en el que se crearon. Defina un objeto de un solo uso dentro del contexto de un único Job o
Dataflow (por ejemplo, scripts y definiciones de transformación específicas).

El tipo de objeto afecta siempre a la forma de definir y recuperar los Objetos

Capítulo 3 – Proyectos
Un proyecto es un objeto reutilizable que permite agrupar Jobs.

Un proyecto es el nivel más alto de organización que ofrece SAP DS. La apertura de un proyecto hace
que un grupo de objetos sea fácilmente accesible en la interfaz de usuario. Puede usar un proyecto para
agrupar Jobs que tienen programaciones que dependen unas de otras o que desea supervisar juntas.
Los proyectos tienen características comunes:

 Los proyectos se enumeran en Local Object Library.

 Solo se puede abrir un proyecto a la vez.
 Los proyectos no se pueden compartir entre varios usuarios.

Capítulo 4 – Jobs
Un Job es el único objeto que se puede ejecutar en SAP DS.

Puede ejecutar y probar manualmente Jobs en desarrollo. En producción, puede programar Batch Jobs y
configurar Jobs en tiempo real como servicios que ejecutan un proceso cuando el software recibe una
solicitud de mensaje.
Un Job se compone de los pasos que desea ejecutar juntos. Cada paso se representa mediante un icono
de objeto que se coloca en el Canvas de trabajo para crear un diagrama de trabajo. Un diagrama de
trabajo se compone de dos o más objetos conectados entre sí. Puede incluir cualquiera de los siguientes
objetos en una definición de Job:

 Dataflows
 Sources
 Targets
 Transformaciones
 Workflows
 Scripts
 Condicionales
 While Loops
 Bloques try/catch

Si un Job se torna complejo, organice su contenido en Workflows individuales y a continuación, cree un

único Job que llame a esos Workflows.

Los Real Time Jobs utilizan los mismos componentes que los Batch Jobs. Puede agregar Workflows y
Dataflows a Batch Jobs y Real Time Jobs. Cuando arrastra un icono de Workflow o Dataflow a un Job,
está indicando al software que valide estos objetos según los requisitos del tipo de Job (ya sea Batch o
Real Time).

Capítulo 5 – Datastores
Los Datastores representan configuraciones de conexión entre SAP DS y las bases de datos o
aplicaciones.

Estas configuraciones pueden ser directas o a través de adaptadores. Las configuraciones de Datastore
permiten al software acceder a los metadatos de una base de datos o aplicación, y leer o escribir en esa
base de datos o aplicación mientras SAP DS ejecuta un Job.

Los Datastores de SAP DS pueden conectarse a:

 Bases de datos y File Systems Mainframes.

 Aplicaciones que tienen adaptadores predefinidos o escritos por el usuario.
 J.D. Edwards One World, J.D. Edwards World, Oracle, PeopleSoft, SAP, SAP Data Quality
Management, SAP NetWeaver BW, Siebel y Google BigQuery.
 Servidores remotos que utilizan FTP, SFTP y SCP.

La información específica a la que puede tener acceso un objeto Datastore depende de la configuración
de la conexión. Cuando cambie la base de datos o la aplicación, realice los cambios correspondientes en
la información del Datastore. El software no detecta automáticamente la nueva información, la
metadata necesita ser reimportada. Así como también las definiciones de los objetos en la Base de
Datos.

Puede crear varias configuraciones para un Datastore. Esto le permite planificar con anticipación para
los diferentes entornos en los que se puede usar su Datastore y limita el trabajo relacionado con la
migración de Jobs. Por ejemplo, puede añadir un conjunto de configuraciones (DEV, QAS y PRD) al
mismo nombre de Datastore. Esta configuración de conexión permanece en el Datastore durante la
exportación o importación. Puede agrupar cualquier conjunto de configuraciones de Datastore en una
System Configuration. Al ejecutar o programar un Job, seleccione una System Configuration y, por lo
tanto, el conjunto de configuraciones de Datastore para el entorno actual.

Capítulo 6 – File Formats

Los File Formats son un conjunto de propiedades que describen la estructura de metadatos de un
archivo plano (ASCII). A su vez, describen la estructura de metadatos de un archivo específico. Un
template de File Format es una descripción genérica que se puede utilizar para varios archivos físicos.
SAP DS puede utilizar datos almacenados en archivos como fuentes y destinos.

Un File Format define una conexión a un archivo. Por lo tanto, se utiliza un File Format para conectarse a
datos de origen o de destino cuando los datos se almacenan en un archivo en lugar de una tabla de base
de datos. Local Object Library almacena plantillas que se utilizan para definir File Formats específicos
como orígenes y destinos en Workflows.

Los File Format pueden describir archivos de los siguientes tipos:

 Delimitado: caracteres como comas o tabulaciones separan cada campo

 Ancho fijo: especifique el ancho de columna
 SAP Transport: se utiliza para definir objetos de transporte de datos en Workflows de
aplicaciones SAP
 Texto no estructurado: se utiliza para leer uno o más archivos de texto no estructurado de un
directorio
 Binario no estructurado: se utiliza para leer uno o más documentos binarios de un directorio

SAP DS puede leer varios archivos con el mismo formato desde un solo directorio utilizando un solo
objeto de origen. También puede identificar el archivo de origen para cada fila del destino, de esta
forma se identifica la fuente de datos.
El punto (.) y la coma (,) son los dos caracteres más comunes utilizados para determinar separadores
decimales y de miles para los tipos de datos numéricos. Al formatear archivos en SAP DS, los tipos de
datos en los que se pueden utilizar estos símbolos incluyen Decimal, Numeric, Float y Double. Puede
utilizar cualquier símbolo para el indicador de miles y cualquier símbolo para el separador decimal. Por
ejemplo: 2.098,65 o 2.089,65.

El editor de File Format proporciona una manera de omitir las filas que contienen un marcador
especificado (o marcadores) al leer archivos. De esta forma también tenemos la posibilidad de leer
archivos parcialmente. Por ejemplo, es posible que desee omitir los marcadores de línea de comentario
como # y //

Asociado a esta característica, dos caracteres especiales el punto y coma (;) y la barra invertida (\) —
permiten definir varios marcadores en el string de marcador de fila a ignorar. Utilice el punto y coma
para delimitar cada marcador y utilice la barra invertida para indicar caracteres especiales como
marcadores (como la barra invertida y el punto y coma).
El valor de marcador predeterminado es una string vacío. Cuando se especifica el valor predeterminado,
no se omite ninguna fila.

Puede especificar un formato de fecha a nivel de campo para sobrescribir los formatos de fecha, hora o
fecha y hora predeterminados establecidos en el área Values.

Por ejemplo, cuando el tipo de dato se establece en Fecha, puede editar el valor del campo Format
correspondiente a un formato de fecha diferente, como los siguientes valores:

 aaaa.mm.dd
 mm/dd/aa
 dd.mm.aa

Capítulo 7 – File Location Objects

Los File Location Objects son objetos reutilizables de primera clase que definen las propiedades de un
protocolo de transferencia de archivos específico.

Los protocolos de transferencia de archivos aplicables son Local, AWS S3, SCP, FTP y SFTP. Además de
especificar los detalles del protocolo de transferencia de archivos, defina un Server Local o Remoto para
el que usted (o el usuario) tenga permiso de acceso. SAP DS almacena los objetos en File Locations en la
pestaña “Formats” de Local Object Library.

Después de crear un File Location, puede asociarlo a un File Format al crear un objeto nuevo o editar un
objeto existente. Para utilizar la información del protocolo de transferencia de File Formats en un
Dataflow, debe asociar un File Location a un origen o destino en un Dataflow.

Los objetos incluyen archivos planos, archivos de esquema anidados (XML/DTD, JSON), Copybooks
COBOL y archivos Excel.

Los archivos Excel y los Copybooks Cobol emparejados con un File Location Object solo se pueden usar
como orígenes en un flujo de datos.

Cuando se utiliza el File Location Object en un Dataflow como origen o destino, SAP DS utiliza la
información del servidor remoto y local y los protocolos de transferencia de archivos desde el File
Location Object para mover una copia de los datos del servidor remoto al servidor local para utilizarlo
como origen en un Dataflow y para cargar los datos de salida generados desde el Dataflow en el servidor
local y, a continuación, en el servidor remoto.

SAP DS proporciona opciones para controlar lo que sucede con los datos existentes cuando transfiere los
datos a un archivo (ya sea archivos remotos o locales). El software puede anexar, sobrescribir, eliminar o
guardar datos en los servidores locales o remotos en función del tipo de File Format, el tipo de protocolo
y el tipo de uso (origen o destino). También puede crear un archivo de datos físico en el servidor local o
remoto si no existe.

Para utilizar la información del protocolo de transferencia de archivos que escribió en un File Location
Object, asocie el objeto con un origen o destino de archivo específico en un Dataflow. También puede
incluir un File Location Object al crear o editar un nuevo formato.

Capítulo 8 – Dataflows
Los Dataflows extraen, transforman y cargan datos. Todo lo que tiene que ver con los datos, incluida la
lectura de orígenes, la transformación de datos y la carga de destinos, se produce dentro de un
Dataflow. Las líneas que conectan objetos en un Dataflow representan el flujo de datos a través de
pasos de transformación de datos.

Después de definir un Dataflow, puede agregarlo a un Job o Workflow. Desde dentro de un Dataflow, un
flujo de datos puede enviar y recibir información hacia y desde otros objetos a través de parámetros de
entrada y salida.

Los nombres de Dataflows pueden incluir caracteres alfanuméricos y caracteres de subrayado (_). No
pueden contener espacios en blanco.

Cada objeto que coloque en el diagrama de flujo de datos se convierte en un paso en el Dataflow.

Puede utilizar los siguientes objetos como pasos en un flujo de datos:

 Fuente
 Target
 Transformación

Las conexiones que realice entre los objetos determinan el orden en que SAP DS ejecuta los pasos.

Los Dataflows son operaciones cerradas, incluso cuando son pasos de otro Dataflow. Los conjuntos de
datos creados dentro de un Dataflow no están disponibles para otros pasos del Workflow.

Durante el diseño inicial de una aplicación, es posible que le resulte conveniente utilizar Template Tables
para representar tablas de base de datos volátiles. Con estos objetos, no es necesario crear inicialmente
una nueva tabla en el DBMS e importar los metadatos en DS. En su lugar, SAP DS crea automáticamente
la tabla en la base de datos con el esquema definido por el Dataflow al ejecutar un Job.

Después de crear una Template Table como destino en un Dataflow, puede utilizarla como origen en
otros Dataflows. Aunque se puede utilizar como tabla de origen en varios Dataflows, solo se puede
utilizar como destino en uno solo.
Estos objetos son especialmente útiles en el desarrollo temprano de aplicaciones cuando se diseña y
prueba un proyecto. Si modifica y guarda la operación de transformación de datos en el Dataflow donde
la Tabla Template es un destino, el esquema de la tabla cambia automáticamente. Las actualizaciones
del esquema se realizan automáticamente en cualquier otra instancia de la tabla. Durante el proceso de
validación SAP DS le advierte de cualquier error que resulten de cambiar el esquema.
Puede utilizar el comando Propagate Column en un flujo de datos para agregar una columna existente
desde un origen de nivel superior o transformar a través de objetos intermedios a un extremo
seleccionado.

Las columnas se agregan en cada objeto sin ningún cambio en el tipo de dato u otros atributos. Cuando
hay más de una ruta de acceso posible entre el punto inicial y el punto final, puede especificar la ruta
para las columnas agregadas.
La propagación de columnas es una operación de extracción. El comando Propagate Column se emite
desde el objeto en el que se necesita la columna. La columna se extrae del origen o transformación
seleccionada y se agrega a cada uno de los objetos intermedios, así como al objeto de extremo
seleccionado.

Capítulo 9 – Platform Transforms

Las transformaciones operan en conjuntos de datos manipulando sets de entrada y produciendo uno o
más sets de salida. Por el contrario, las funciones trabajan con valores únicos en columnas específicas de
un Dataset. Muchas transformaciones integradas están disponibles en la biblioteca de objetos de la
pestaña Transforms.
Las transformaciones que puede utilizar dependen del paquete de software que haya adquirido. (Si una
transformación pertenece a un paquete que no ha comprado, se deshabilita y no se puede usar en un
Job).
Las transformaciones se agrupan en las siguientes categorías:

 Data Integrator: Transformaciones que le permiten extraer, transformar y cargar datos. Estas
transformaciones ayudan a garantizar la integridad de los datos y maximizan la productividad
del desarrollador para cargar y actualizar el entorno.

 Data Quality: Transformaciones que ayudan a mejorar la calidad de los datos. Estas
transformaciones pueden analizar, estandarizar, corregir, enriquecer, hacer coincidir y
consolidar sus entidades de información operacional y de clientes.

 Platform Transforms: Transformaciones necesarias para las operaciones generales de

movimiento de datos. Estas transformaciones le permiten generar, asignar y combinar filas de
dos o más orígenes, crear operaciones de consulta SQL (expresiones, búsquedas,
combinaciones y filtros), realizar la división condicional y enmascarar datos personales para
mantener los datos confidenciales relevantes, anónimos y seguros.

 Text Data Processing: Transformaciones que le ayudan a extraer información específica de su

texto. Pueden analizar grandes volúmenes de texto, lo que le permite identificar y extraer
entidades y hechos, como clientes, productos, ubicaciones e información financiera relevante
para su organización.

Capítulo 10 – Workflows
Un Workflow define el proceso de toma de decisiones para ejecutar hilos de trabajo. Por ejemplo, los
elementos de un Workflow pueden determinar la ruta de acceso de ejecución en función de un valor
establecido por un Job anterior o pueden indicar una ruta de acceso alternativa si algo sale mal en el
thread de ejecución principal. En última instancia, el propósito de un Workflow es prepararse para
ejecutar flujos de trabajo y establecer el estado del sistema una vez completados los flujos.
Los Jobs son Workflows especiales porque puede ejecutarlos. Casi todas las entidades documentadas
para los Workflows también se aplican a los Jobs, con una excepción: los Jobs no tienen parámetros.

Los pasos de Workflow adoptan la forma de iconos que se colocan en el Canvas de trabajo para crear un
diagrama de flujo.

Los siguientes objetos pueden ser elementos en Workflows:

 Dataflows
 Workflows
 Scripts
 Condicionales
 While Loops
 Bloques try/catch

Los Workflows pueden llamar a otros Workflows y puede anidar llamadas a cualquier profundidad. Un
Workflow también puede llamarse a sí mismo.
Las conexiones que realice entre los iconos del Canvas de trabajo determinan el orden en que se
ejecutan los Workflows, a menos que los Jobs que contienen esos Workflows se ejecuten en paralelo.

Capítulo 11 – Conditionals
Los condicionales son objetos de un solo uso que se utilizan para implementar la lógica if/then/else en
un Workflow.

Los condicionales y sus componentes (if, then y else) se incluyen en el ámbito de las variables y
parámetros del flujo de control primario. Para definir un condicional, especifique una condición y dos
bifurcaciones lógicas:

 IF – Expresión booleana que se evalúa como TRUE o FALSE. Puede utilizar funciones, variables y
operadores estándar para construir la expresión.
 THEN – Elementos de Workflow que se van a ejecutar si la expresión If se evalúa como TRUE.
 ELSE – (Opcional) Elementos de Workflow que se van a ejecutar si la expresión If se evalúa
como FALSE.

Capítulo 12 – While Loops

El While Loop es un objeto de un solo uso que puede utilizar en un Workflow. Utilice un While Loop para
repetir una secuencia de pasos en un Workflow siempre que se cumple una condición determinada.

Normalmente, los pasos realizados durante el While dan como resultado un cambio en la condición para
que la condición finalmente ya no se cumpla y el Workflow salga del bucle. Si la condición no cambia, el
While no finalizará.
Por ejemplo, es posible que desee que un Workflow espere hasta que el sistema escriba un archivo
determinado. Puede utilizar un While para comprobar la existencia del archivo mediante la función
“file_exists”. Mientras el archivo no exista, puede hacer que el Workflow entre en modo de suspensión
durante un período de tiempo determinado, por ejemplo, un minuto, antes de volver a comprobarlo.
Dado que es posible que el sistema nunca escriba el archivo, debe agregar otra comprobación al bucle,
como un contador, para asegurarse de que el While finalmente se cierra. En otras palabras, cambie el
While para comprobar la existencia del archivo y el valor del contador. Mientras el archivo no exista y el
contador sea menor que un valor determinado, repita el bucle while. En cada iteración del bucle,
coloque el Workflow en modo de suspensión y, a continuación, incremente el contador.
Capítulo 13 – Try-Catch
Un bloque try/catch es una combinación de un objeto try y uno o más objetos catch que permiten
especificar flujos de trabajo alternativos si se producen errores mientras el software está ejecutando un
Job. Por ejemplo, excepciones producidas por el software, el DBMS o el sistema operativo.

Aplique las soluciones para los grupos de excepciones o para errores específicos dentro de un grupo.

Los objetos Try y catch son objetos de un solo uso. Este es el método general para implementar el
control de excepciones:

 Inserte un objeto try antes de los pasos para los que está controlando errores.
 Inserte un objeto catch en el Workflow después de los pasos.
 En el objeto catch:
o Seleccione uno o más grupos de errores que desee detectar.
o Defina las acciones que ejecuta una excepción producida. Las acciones pueden ser un
único objeto de script, un Dataflow, un Workflow o una combinación de estos objetos

Si se produce una excepción durante la ejecución de un bloque try/catch y si ningún objeto catch está
buscando esa excepción, la lógica de error normal controla la excepción.

Capitulo 14 – Scripts
Los scripts son objetos de un solo uso que se utilizan para llamar a funciones y asignar valores a
variables en un Workflow o un Job.

Por ejemplo, puede utilizar la función SQL en un script para determinar la hora de actualización más
reciente de una tabla y, a continuación, asignar ese valor a una variable. A continuación, puede asignar
la variable a un parámetro que pase a un Dataflow e identifique las filas que se van a extraer de un
origen.
Un script puede contener las siguientes instrucciones:

 Llamadas a funciones
 Instrucciones If
 Declaraciones while
 Instrucciones de asignación
 Operadores

Las reglas básicas para la sintaxis del script son las siguientes:

 Cada línea termina con un punto y coma (;)

 Los nombres de variable comienzan con un signo de dólar ($)
 Los valores de cadena se encierran entre comillas simples (')
 Los comentarios comienzan con un signo de almohadilla (#)
 Las llamadas a funciones siempre especifican parámetros, aunque la función no utilice ningún
parámetro.
Capítulo 15 – Real time Jobs
El software admite la transformación de datos en tiempo real. En tiempo real significa que el software
puede recibir solicitudes de sistemas ERP y aplicaciones web, y enviar respuestas inmediatamente
después de obtener los datos solicitados de una caché o una segunda aplicación. Las operaciones para
procesar mensajes a petición se definen mediante la creación de Jobs Real Time en el SAP DS.

El contenido del mensaje puede variar. Podría ser un pedido de ventas o una factura procesada por un
sistema ERP destinada a una caché de datos, podría ser una solicitud de estado de pedido generada por
una aplicación web que requiere una respuesta de una caché de datos o un sistema de back-office.

El Access Server escucha constantemente los mensajes entrantes. Cuando se recibe un mensaje, el
Access Server rutea el mensaje a un proceso en espera que realice un conjunto predefinido de
operaciones para el tipo de mensaje. El Access Server entonces recibe una respuesta para el mensaje y
las respuestas a la aplicación de origen.

Los Jobs Real Time extraen datos del cuerpo del mensaje recibido y de cualquier origen secundario
utilizado en el Job.

Al igual que un Batch Job, un Job Real Time extrae, transforma y carga datos. Cada Job Real Time puede
extraer datos de un único tipo de mensaje. También puede extraer datos de otros orígenes, como tablas
o archivos.
Las mismas transformaciones puede definir en Jobs Batch están disponibles en los Jobs Real Time. Sin
embargo, puede usar las transformaciones de forma diferente en los Real Time. Por ejemplo, podría
usar bifurcaciones y controles lógicos con más frecuencia de la que usaría en los Jobs por lotes.

También en Jobs Real Time, SAP DS escribe datos en destinos de mensajes y destinos secundarios en
paralelo. Esto garantiza que cada mensaje reciba una respuesta lo antes posible.
A diferencia de los Jobs Batch, no se ejecutan en respuesta a una programación o desencadenador
interno. En este caso, los Jobs Real Time se ejecutan como servicios en tiempo real iniciados a través del
Administrador en Management Console. Los Servicios Real Time esperan los mensajes del Access Server.
Cuando éste recibe un mensaje, pasa el mismo a un servicio en tiempo real diseñado para procesar este
tipo de mensaje. El servicio en tiempo real procesa el mensaje y devuelve una respuesta.
Posteriormente, continúa escuchando y procesando mensajes a petición hasta que recibe una
instrucción para cerrar.

Sugerencias de Diseño
Al diseñar Workflows en Jobs en tiempo real, hay reglas que deben seguirse.

 Si incluye una tabla en un Join con un origen en tiempo real, SAP DS incluye el conjunto de
datos del origen en tiempo real como el loop externo de la combinación. Si se incluye más de
un origen complementario en la combinación, puede controlar qué tabla se incluye en el
siguiente bucle más externo de la combinación utilizando los Join Ranks de las tablas.
 En los Jobs Real Time, no almacene en caché datos de orígenes secundarios a menos que los
datos sean estáticos. Los datos se leerán cuando se inicie el Job y no se actualizarán mientras se
ejecuta.
 Los mecanismos de recuperación no se admiten en los Jobs en tiempo real.

Capítulo 16 – Embedded Dataflows

Un Embedded Dataflow es un Dataflow al que se llama desde dentro de otro Dataflow. SAP DS
proporciona opciones fáciles de usar para crear Dataflows Embebidos.

Los datos entran o salen del Embedded Dataflow desde el flujo primario a través de un único origen o
destino. Puede contener cualquier número de orígenes u destinos, pero solo una entrada o una salida
puede pasar datos hacia o desde el Dataflow primario.

Un Embedded Dataflow es una ayuda de diseño que no tiene ningún efecto en la ejecución del Job.
Cuando se ejecuta el Dataflow primario, expande los Embedded Dataflow, optimiza el Dataflow primario
y, a continuación, lo ejecuta.

Utilice los Embedded Dataflow para:

 Simplificar la visualización: Agrupe secciones de un Dataflow en Embedded Dataflow para

permitir un diseño y una documentación más claros.
 Reutilizar la lógica: Guarde las secciones lógicas de un Dataflow para que pueda utilizar la
lógica exacta en otros Dataflows o proporcionar una manera sencilla de replicar la lógica y
modificarla para otros flujos.
 Segregar acciones: Replique secciones de un Dataflow como Embedded Dataflows para poder
ejecutarlos de forma independiente.

Capitulo 17 – Substitution Parameters

Utilice el mismo Parámetro de Sustitución en varios objetos para establecer eficazmente el mismo valor
en una ubicación en lugar de editar cada objeto por separado.

Cuando se utilizan parámetros de sustitución, sólo es necesario editar el valor una vez en la ventana
Variables para cambiar el valor en todos los objetos que utilizan el parámetro. Por ejemplo, si crea un
Job que hace referencia a un directorio único en el equipo local y exporta ese Job a otro equipo, el Job
buscará el directorio único en el nuevo entorno. Si ese directorio no existe, el Job no se ejecutará.
Cuando se utilizan parámetros de sustitución, el software actualiza automáticamente ese valor en todos
los objetos que utilizan el parámetro.

Para mayor comodidad, puede configurar un grupo de parámetros de sustitución para un entorno de
tiempo de ejecución determinado asociando sus valores constantes en una configuración de parámetros
de sustitución. Cree varias configuraciones para agrupar parámetros de sustitución basados en un
entorno de tiempo de ejecución, por ejemplo. De esta forma, puede controlar muchos valores
diferentes cambiando las configuraciones.

Utilice parámetros de sustitución en expresiones, instrucciones SQL y constantes. Los Parámetros de

Sustitución pueden aparecer como un valor en muchas opciones y editores de expresiones para que
pueda elegir una variable de sustitución específica de una lista de valores, así como también en las
configuraciones de los Objetos

Los Parámetros de Sustitución difieren de las variables globales en la forma en que afectan a los Jobs.

Los Parámetros de Sustitución se aplican en el nivel de repositorio. Las variables globales solo se aplican
al Job en el que se definen. Por ejemplo, se usa una variable global para un valor de parámetro que no
se calcula hasta que se ejecuta el Job, mientras que se usa un Parámetro de Sustitución para las
constantes que no cambian durante la ejecución. Un Parámetro de Sustitución definido en un
repositorio local está disponible para todos los Jobs de ese repositorio. Por lo tanto, el uso de un
parámetro de sustitución significa que no es necesario definir una variable global en cada Job para
parametrizar un valor constante.

Capítulo 18 – System Configurations

Una System Configuration agrupa un conjunto de configuraciones de Datastore y una configuración de

Parámetros de Sustitución.

Una configuración de Parámetro de Sustitución se puede asociar a una o más System Configurations. Por
ejemplo, puede crear un System Configuration para el sistema local y otra diferente para el sistema
remoto. Dependiendo de su entorno, ambas pueden apuntar a la misma configuración de Parámetro de
Sustitución o cada una puede requerir una configuración de Parámetro de Sustitución diferente.

En el momento de la ejecución del Job, puede establecer la System Configuration y el Job se ejecutará
con los valores de la configuración de Parámetros de Sustitución asociada.

Capítulo 19 – Pushdown
El optimizador siempre intenta primero realizar una operación full push down. Una operación Full push
down es cuando todas las operaciones de transformación se pueden insertar en las bases de datos y los
Dataflows directamente desde la base de datos de origen a la base de datos de destino. SAP DS envía
SQL INSERT INTO... SELECT a la base de datos de destino donde SELECT recupera datos del origen.

SAP DS realiza full push down cuando se cumplen las siguientes condiciones:

 Todas las operaciones entre la tabla de origen y la tabla de destino son validas para la base de
datos.
 Las tablas de origen y de destino proceden del mismo Datastore y Schema, están en Datastores
que tienen un DB Link definido entre ellas o si el Datastore ha vinculado servidores remotos.

Para mas detalles sobre Optimizacion, SAP Data Services cuenta con una guia con Best Practices en el
siguiente documento