EG Stored Processes vs Autocall Macros?

[deleted_user]

Our organization is trying out EG with Integration Technologies. We're evaluating converting our standard autocall macros to stored processes. Can anyone suggest good methods in EG for handling the following situation? We have about 20 macros that are used by 20+ people. Each of the macros performs a series of steps on whatever input data set is specified. The input data sets have different variables in them. Macro parameters allow choosing input data sets and selecting variables for different roles. The steps often include running a proc, manipulating ODS output data sets and exporting to Excel. We are planning on using code nodes to call the existing macros from an autocall library. Is there a better way to offer this functionality in EG?

I’d also like to check whether some of my tentative conclusions about stored processes are correct.

1 – Stored processes can only use libnames assigned in metadata, not libnames assigned in EG sessions.

2 – If a stored process is included in a process flow, it does not have access to any work data sets created by previous steps in the process flow.

3 – If a stored process includes code that should be executed conditional on the value of the parameters, you need to include a macro in the body of the source code for the stored process (or autocall a macro).

4 – Parameter selection lists can not be automatically created as lists of the variables in a data set (you can get the values of a variable, but not a list of variables).

5 – EG can not provide dynamic selection lists yet.

Thanks for any help,
Paulette

[Cynthia_sas]

Hi, Paulette:
Here goes....

1 – Stored processes can only use libnames assigned in metadata, not libnames assigned in EG sessions.

Partly true. Stored processes can only use libnames for data that are assigned in the metadata OR that you point to INSIDE the stored process with a LIBNAME statement. You have 2 choices -- inside the stored process -- use the META engine (and get all the security, etc) or don't use the META engine and use the physical server path for the data (in which case, you essentially bypass a lot of the benefits of the metadata.)



2 – If a stored process is included in a process flow, it does not have access to any work data sets created by previous steps in the process flow.

True.


3 – If a stored process includes code that should be executed conditional on the value of the parameters, you need to include a macro in the body of the source code for the stored process (or autocall a macro).

True, if you want to use macro conditional logic -- I would amend your statement to say: you need to include a macro call or macro definition in the body of the stored process code ....
[pre]
%macro mymac;
...macro conditional code;
%mend mymac;

*ProcessBody;
%stpbegin;
...some SAS code;
%mymac;
...possibly more SAS code;
%stpend;
[/pre]

When your Platform is installed, there's an automatic location assigned for AUTOCALL macros, FORMAT libraries and code snippets for including -- it is under the LEV1 directory -- so if you didn't want to have the macro definition in the stored process, you could put it in the autocall location.


4 – Parameter selection lists can not be automatically created as lists of the variables in a data set (you can get the values of a variable, but not a list of variables).

Well, you could build your list from dictionary.tables or sashelp.vcolumn-- this is not as elegant as just getting the list of variables directly by pointing to the data set name -- however, it would work. I can make a dataset of variable names by running this in a code node:
[pre]
proc sql;
create table work.classvalt as
select name, format, label, type
from sashelp.vcolumn
where libname = 'SASHELP' and
memname = 'CLASS';
quit;

proc print data=work.classvalt;
run;

proc contents data=work.classvalt;
run;

[/pre]
So, it should be possible to make a list of variable names that you could use for the parameter selection. The stored process wizard in EG lets you populate the list from a file or, even from a SAS dataset (I think).


5 – EG can not provide dynamic selection lists yet.

True -- but not just of EG -- you can't have dynamic selection lists in the Add-in or in Web Report Studio, either. If you did your own custom front end -- either HTML or JSP or ... some other language -- then you could code your own dynamic lists -- but this is one of the most requested features and it is being worked on. I'm not exactly sure when it will be delivered. The hitch in the giddyup is that dynamic selections have to work in ALL client applications -- so it's better to design and implement something that works for them ALL rather than have something that will work in one but make everybody wait for it to work with the other client apps.


cynthia