Defining Aliases within your Datastore in Data Services When developing code within SAP’s Data Services enterprise information management tool; generally requirements dictate to extract and load data across multiple environments. Data Services utilizes datastores to allow you to connect to a variety of different data sources such as a web service, an adapter, or more commonly a database. Those database data sources can include everything SQL Server, Oracle, DB2, even Netezza. This blog will describe setting up datastores against a Netezza database to utilize the alias functionality to simplify the process of migrating code from development to production.

What is Netezza and how does Data Services connect to it? Netezza is a powerful Data Warehousing appliance that integrates the database, server, and the storage components into a single system. Netezza is purpose-built for data warehousing and is specifically designed for running complex data warehousing workloads. As a result of using proprietary architecture to deliver fast query performance, minimal tuning and administration, and high scalability; Netezza is an ideal database system to use for your data warehousing needs. As with any relational database system, Data Services can easily connect to Netezza using a datastore connection. Data Services can then import the metadata that describes the data through that connection. If the metadata is identical across multiple environments you can have multiple data configurations within one datastore:

Having multiple configurations within one datastore eliminates the need to create a datastore for every single database you need to connect to; which can speed up development time and prevents unnecessary clutter in your local object library. But are there any differences in how Data Services connects to Netezza database tables, as opposed to say SQL Server tables?

How Data Services Intereprets Netezza Owner Names One key difference between how Data Services connects with Netezza as compared to say SQL Server, is how it interprets owner names. When you create an object in SQL Server, the default owner is usually “dbo”. When you create an object in Netezza, the default owner is usually “admin”. The difference in how Data Services reads the owners is that for SQL server, the actual owner name (dbo) will be read when importing metadata or creating template tables in that environment. For Netezza, Data Services reads the name of the database as the owner name, not the actual Netezza owner name of that object. For example, let’s say you have a dataflow that extracts data from a single source table from the STAGE datastore that points to the STAGINGTEST database with the owner name admin:

As you can see from the images above the EMPLOYEE table is sourced from the STAGINGTEST database using the owner ‘STAGINGTEST’ which is the database not the owner name. How Data Services reads owner names of table objects is something to always keep in mind when working with various database platforms. Now that we have that out of the way, let’s discuss a case scenario for defining aliases.

Case Scenario We will continue to use the images above as part of our case scenario example. In this example, STAGINGTEST would be the environment the development and subsequent testing of your dataflow would take place. The production repository you are migrating to only contains the production datastore connections, and the production table owner names which in this case would be named STAGE not STAGINGTEST:

When you ‘get latest’ on that dataflow into the production repository you would then see two versions of the table, the table with the production table owner and the table you just migrated with the development table owner:

When attempting to execute the job, the job will fail against the Netezza database with a “Cross Database Access” error:

So how do you resolve this? Do you create another datastore configuration that points to the production database in your local repo and then switch the default configuration before migrating to PROD? That would cause the same error because the table owner you have already specified for your source table is still STAGINGTEST. Plus you may not have access to the production environment from your local repository. Do you create two separate datastores (prod and dev, if you have access) and two different versions of your dataflow, one to test and one to move to production? You could but that would mean unnecessary extra development time. This situation is what makes defining aliases in your datastores so beneficial.

Defining Aliases Defining aliases in Data Services allows you to substitute your specified datastore configuration alias for the real owner name when you import metadata for database objects. Therefore, when you are migrating from development to production, Data Services uses the alias you have defined in your datastore to automatically change the table owner name with the table owner name of your choice. In this case, that owner name would be the production owner name: STAGE.

To define an alias in your datastore:

1) Right click the datastore in question and click edit:

2) Then click the Advanced button, then the Edit button again:

3) Scroll down to the bottom of your configuration, click on the Aliases (Click here to create) section, and a ‘Create New Alias’ icon box will pop up:

4) Type the name of your production table owner, ‘STAGE’ then next to the Alias name under the Configuration tab; list the name of the actual table owner of the table you are utilizing…..in this case STAGINGTEST:

5) Now when you import your source table from the STAGINGTEST database…even though you are using the STAGINGTEST table owner, DATA SERVICES reads the alias of that owner as STAGE:

Data Services allows you to speed up development time and simplify the process of migrating code from development to production by using the alias functionality in your datastore configuration to do the work of remapping owner names when moving across various database environments.

Shaun Scott, Business Intelligence Consultant Decision First Technologies [email protected]

Shaun Scott is a business intelligence consultant specializing in data warehousing and ETL development. Shaun delivers customized SAP BusinessObjects solutions for customers across all industries. With Decision First Technologies, Shaun utilizes SAP Data Services, Universe Design, Web Intelligence, and a variety of database technologies, including SQL server, DB2, and Netezza.