Global code in SAS Data Integration Studio

[jdmarshg]

Hello everyone,

I was wondering if anyone knows of a way to create a global use of code at the folder level.

Meaning that all jobs and folders below have access to code/user written etc..

When there are updates I would like to just change one set of code whether is be a transformation and or user written and it reflects across all jobs and areas

where this code has been placed.

Any suggestions or ideas on how this would be created.

[jakarman]

The question you are describing is default behavior with:

- SAS metadata folders

- On windows and Mainframe host authorisation it also default behavior on folders/naming .

  Unix host authorisation only when you you have the gid-bit set on the directory levels. Advisable to have the stciky-bit also set.   

So my conclusion with this very little informatin you have given is: Coorect the Host (Unix) security in a proper approach.

If you need tools to adjust Job properties in the SAS metadata, that also exists.

[jdmarshg]

Jaap,

I will pass this on to the administration as I also have little information.

From a developers perspective from using a different ETL tool SSIS to now using SAS DI I'm trying to learn what is and is not possible as far as usage of code / scope of code for the whole environment. I'm not set for training until later this month regarding administration.

Right now user written code and transformations have to be added to each and every job. I wanted to see if there is a way to call code in a centralized area.

Also that the code can be updated at one place and it reflect in all places the code is placed.

My apologies as I'm collecting more information as I go.

[jakarman]

No problem as you are asking with sensible reasons.

From you developers standpoint you would like to have an delivered ready envrironment. Very sensible.

Think of libraries filenames and other settings (options).

The platform admin can set those as part of user-mod configuratios files when you have a dedicate app-server context for your project.

That is a different role when maintaining than the DI building part, some parts are correlated.

The other approach is having the same definitions defined for all jobs in a own defined pre-code setting. Less sophisticated and less maintainable.

Those kind of things are seeming of a higher level to be architectural part even than ...

I do not think the will tell everything about this not at your scheduled training or by your admins.

[DaveR_SAS · Accepted solution]

jd, perhaps you already know, this, but both the properties window for an entire DI Studio job, and the property windows for the transformations within a job have a Code tab. That tab has a Code Generation Mode control that enables you to replace the default, generated code for the object with user-written code. If you click the Folder icon on that tab, you can navigate to a code file on the file system or link to a code file on the file system.

The DI Studio user guide chapter "Working with User-Written Code" might help you understand the various ways that user-written code can be used in DI Studio:

SAS(R) Data Integration Studio 4.7: User's Guide

The topic "Replacing the Generated Code for a Job or Transformation" might be the closest thing to what you want to do:

SAS(R) Data Integration Studio 4.7: User's Guide

[jakarman]

I was aiming at: http://blogs.sas.com/content/bi/2012/10/29/choosing_an_autoexec/

As solving the generic questions at a more generic level makes it more logical.
Just some axioma's of golden prgramming rules:

- do not hard code physical names in applications programs

- do not hard code access-information like account and password information in application programs. 
As some pity DI generated code is sometimes violating these kind of rules. Making normal promoting of code impossible. Common promoted approaches are still a fake like: the example of using pwencode as it is still elivering something to be copied/paste for reuse and not isolating environments D,T,A,P. 

[LinusH]

I think we are missing an import point here, about differences between DIS and SSIS. In SSIS (I believe) you can in more situations reuse implemented transformations as templates.

The closest thin in DI are User Written Transformations. But they are, as the name suggests, user written, and usually less metadata driven than SAS supplied transformations.

As with non-DI SAS implementations you can generalize code using macros, but these have no connection to metadata, so not recommended.

Depending on the requirements, you could build jobs as generic as you can, and then have them called by other jobs (outer jobs). This would usually not be as intuitive as normal ETL development, and could be a higher cost for maintenance in the end.

So as my bottom line, there could be a need for further development of the product in this topic.

[jdmarshg]

These are all excellent points I will read the documentation and see how I can expand the User Written Code to handle the needs of a fast grown environment.

Trying to find the easiest way to change the environment direction before its so large the task becomes much more tedious and time consuming.

I will update with any solutions I might find useful and bounce them off you guys for feed back.

Very informative thank you ....

[jdmarshg]

What I ended up using thus far is nothing more then a %include to sas code that can be changed in one place to reflect across many areas.

I'm still testing this temporary solution as a workaround.