DSXchange

Looking to connect DataStage ActiveX (COM) controls to a third Party for test automation. Can this be done through routines/plug-ins?

Why complicate something so simple?

DataStage jobs DO something. All you need to do is run the jobs. What would you vary, job parameters? Different data in the source and target? The jobs are static.

Just run the jobs when necessary via the command line interface program dsjob.

Running jobs has always been the easy part of testing, verifying results has always been the hard part. Automation of jobs can be done via the API but all that time would probably give you very little benefit. It's having a good regression testing strategy with static test data and a tool to verify that the results are what is expected that is more valuable.

vmcburney wrote:Running jobs has always been the easy part of testing, verifying results has always been the hard part. Automation of jobs can be done via the API but all that time would probably give you very little benefit. It's having a good regression testing strategy with static test data and a tool to verify that the results are what is expected that is more valuable.

Can you point me to the API? I looked in the documentation and could not find it

The Server Job Developer's Guide (servjdev.pdf) Chapter 19: DataStage Development Kit (Job Control Interfaces).

Has anyone exported the routines output to an ActiveX DCOM Server? Our intention is to schedule and save DataStage output to a test management repository.

sengleb wrote:Has anyone exported the routines output to an ActiveX DCOM Server? Our intention is to schedule and save DataStage output to a test management repository.

Anyone have any thoughts on this? :D

Define output. Are you talking logs?

No, routines parameters values that are returned from C++ functions that come from the Datastage API.

We are struggling to understand because the type of test automation you are trying to get is something most of us have never tried, nor would ever try. The cost benefit of automating the running of DataStage jobs through a test tool is dubious. This is not a end user GUI tool where test automation ensures the save, cancel and help buttons works. This is an ETL job. Most of us work on a layer of job control either through BASIC routines, 3rd party scheduling tools or sequence jobs and we code in the error handling into this layer. Therefore we have an easy way to start all jobs via this job control and we have an easy way to verify results via reports. So who needs test automation? You are duplicating effort. You will end up building test automation job control and normal job control.

vmcburney wrote:We are struggling to understand because the type of test automation you are trying to get is something most of us have never tried, nor would ever try. The cost benefit of automating the running of DataStage jobs through a test tool is dubious. This is not a end user GUI tool where test automation ensures the save, cancel and help buttons works. This is an ETL job. Most of us work on a layer of job control either through BASIC routines, 3rd party scheduling tools or sequence jobs and we code in the error handling into this layer. Therefore we have an easy way to start all jobs via this job control and we have an easy way to verify results via reports. So who needs test automation? You are duplicating effort. You will end up building test automation job control and normal job control.

The exact reasoning for the "job control" is the reason for the test repository direct linkage. The automation aspect is only for job control and automatic saving of test runs and test results in that repository. Something that doesn't seem to be duplication since it doesn't exist as far as the direct linkage of DataStage results to the client test repository. Extending the functionality into the format and function of the testing team charter is all the that is being attempted.

dsobjects.dll is already a COM object. One of the objects exposed therein is a Subroutine object which can, of course, return values. But it's probably a cumbersome approach, and you need to establish a connection to DataStage using a Session object. "They" don't provide any documentation on this, but the IBM manual "UniObjects" will get you close.