What is it about?

This is a Destination Element, in a pipeline, which consumes a single given input (which is a table in our platform) and uploads the data to a customer-provided Azure / MS SQL table. This means that, each time this Action is executed, the whole contents of a table in the platform are dumped (inserted) into the customer-provided table.

What are the pre-requisites to use this action?

The pre-requisites to use this pipeline action are:

• The customer must be authorized into an already existing Azure / MS SQL Server instance of their own.
• A desired table, with a desired structure and fields, must exist inside that instance, being such table the target to dump the (in-platform) data into. It must have the appropriately desired columns.
• A user with permissions to write in the desired table(s) must exist in that server instance. That user will be authorized for the customer to give their credentials to our platform. This user must have write permissions but, as a recommendation security, it must only have permissions into that desired table (and/or other tables that are meant to be populated by other usages of this action).
• A workspace, with a project, and a pipeline in that project. Such pipeline must have a preceding integration node (or even better: any node that produces an SQL table in our platform). The Azure action must take one of those nodes are its only input. This will be described in the next section.

Example layout and configuration

A minimal sample pipeline layout would look like this:

Components:

1. A source integration, to draw data from.
2. A middle node, which would sub-select or convert the input data to a new format or set of columns. The format would be chosen carefully, since it will serve for the next step and must be a compatible set of columns to upload.
3. The Azure SQL node, which will have the task of uploading the data in the incoming format from the middle node.

By compatible, this must be understood:

1. The target dump table will have many fields. Some of them may be optional (with a default value or automatic setting on absence), and some of them may be required (with no default value or automatic setting on absence).
2. The middle node will have a specific set of columns in its generated table.
3. The Azure node will be configured to map fields from the middle node to fill all the required fields and, perhaps, some optional fields. In each case, however, the type of the fields in both sides of the mapping must match (e.g. mapping a string field in the middle to a string field in the dump table, or a datetime field in the middle to a datetime field in the dump table, ...).

For example, the credentials are set like this: