Desktop productivity for business analysts and programmers

SAS Enterprise guide limitations?

Accepted Solution Solved
Reply
Contributor
Posts: 46
Accepted Solution

SAS Enterprise guide limitations?

HI,

Is SAS Enterprise guide a major part of the SAS Architecture in the SAS EBI platform? if yes, is it widely used for development purpose as opposed to being merely used by power users? I hear a lot of people saying SAS EG is only best used for testing whereas Information Map studio and Web report studio are better for development purpose. Is this really true?

I'd like opinions with quoting some of your real time experiences please.

Thanks.


Accepted Solutions
Solution
‎09-28-2014 10:19 AM
Trusted Advisor
Posts: 1,052

Re: SAS Enterprise guide limitations?

I've been a heavy user of Enterprise Guide for close to ten years, and I certainly have some experience in the domain you describe. Let me try to tackle a few of your threads (to mix a metaphor).

Yes, I believe that Enterprise Guide (EG) is a major part of SAS' architecture. It meets the need to have a fat client, highly functional Windows interface to the SAS environment.

Yes, EG is very heavily used for development. In my opinion, if you're connected to a multi-server SAS environment with a SAS metadata server intermediating your data accesses, I believe that EG is considerably superior to the older Display Manager interface, for a number of reasons I can expand on if you wish.

EG is also an excellent tool for exploratory data analysis, meeting the requirement to i) obtain data from diverse sources, ii) transform that data into the form that you need for further analysis, and iii) analyse the data. This is why LinusH describes it as used by "power user, data analysts, statisticians"

Where you need to differentiate EG from the SP and DIS environments is in the area of repeatability. If you have a function that will be required on a repeated basis by one or more users, as LinusH explains it should be developed and "packaged" using the DIS and SP products; the functionality can then be exposed to users through EG, AMO, WRS, etc.

On the other hand, if your exploration is a "one-off", in other words once you get your results you're finished, than EG is a superb tool for doing this, and I can't recommend it highly enough. Using the DIS and SP environment has overheads relating to professional system development, which you don't need.

Another differentiator is the quality of reporting required. SAS has extensive report development toolkits, and not surprisingly, the more complex the report the more difficult it is to create. Broadly, if the reports are straightforward and nit-picking formatting aren't necessary, EG out of the box will do the job. If you need either of the above, you'll need to get into more sophisticated tools.

Hope this helps!
  Tom

View solution in original post


All Replies
SAS Employee
Posts: 232

Re: SAS Enterprise guide limitations?

Hello, I am moving this to the Enterprise guide community to help you get an answer more quickly

Esteemed Advisor
Posts: 5,198

Re: SAS Enterprise guide limitations?

There are no absolute truth of waht EG is or is not. It's a fleible tool and diffrent presons use it in diffrent situations.

If you explain why you ask we ight give you a more precise answer.

EG, yes, many power user, data anlysysts, staticians, developers (for testing and data qualification urposes) etc.

Information Maps are created for standardised reporting, to hide complex table relations (star schemas for instance). Maps can be used by poser users in EG, and by other applications.

WRS is a tool for creating standardised reports, which allow some, not much, flexibility.

Specialized report are usually created by Stored Process, which could be created from EG.

And then there is Add in for MS Office. And Visual Anaytics, and...what are your requirements?

True, or not, what was the question again?

Data never sleeps
Contributor
Posts: 46

Re: SAS Enterprise guide limitations?

My requirement is Bi reporting fetching data from datamarts. These are balance sheet summary reports, certain tabulation, comparison reports etc or other similar reports for asset liability management in financial services. SAS EG generally gets negative feedback when intending to use that for report development purpose for my above requirement. I wonder why. Many at my office say EG is nothing more than a testing tool in real time scenario and not to use that for development. Even for stored process, they are suggesting SAS DI studio and not EG.

Can you help my understanding?

Esteemed Advisor
Posts: 5,198

Re: SAS Enterprise guide limitations?

Yes, you can do StP in DI Studio, but I would NOT recommend that for reports! DIS is for ETL or ETL-like processing.

You can see EG as Base SAS programming environment, and for free programming, I think it's good.

But it's always hard to tell on beforehand which developers likes which tool.

Simpler summary and comparison reports sounds like they could be done in WRS (on underlying info maps?)

Data never sleeps
Solution
‎09-28-2014 10:19 AM
Trusted Advisor
Posts: 1,052

Re: SAS Enterprise guide limitations?

I've been a heavy user of Enterprise Guide for close to ten years, and I certainly have some experience in the domain you describe. Let me try to tackle a few of your threads (to mix a metaphor).

Yes, I believe that Enterprise Guide (EG) is a major part of SAS' architecture. It meets the need to have a fat client, highly functional Windows interface to the SAS environment.

Yes, EG is very heavily used for development. In my opinion, if you're connected to a multi-server SAS environment with a SAS metadata server intermediating your data accesses, I believe that EG is considerably superior to the older Display Manager interface, for a number of reasons I can expand on if you wish.

EG is also an excellent tool for exploratory data analysis, meeting the requirement to i) obtain data from diverse sources, ii) transform that data into the form that you need for further analysis, and iii) analyse the data. This is why LinusH describes it as used by "power user, data analysts, statisticians"

Where you need to differentiate EG from the SP and DIS environments is in the area of repeatability. If you have a function that will be required on a repeated basis by one or more users, as LinusH explains it should be developed and "packaged" using the DIS and SP products; the functionality can then be exposed to users through EG, AMO, WRS, etc.

On the other hand, if your exploration is a "one-off", in other words once you get your results you're finished, than EG is a superb tool for doing this, and I can't recommend it highly enough. Using the DIS and SP environment has overheads relating to professional system development, which you don't need.

Another differentiator is the quality of reporting required. SAS has extensive report development toolkits, and not surprisingly, the more complex the report the more difficult it is to create. Broadly, if the reports are straightforward and nit-picking formatting aren't necessary, EG out of the box will do the job. If you need either of the above, you'll need to get into more sophisticated tools.

Hope this helps!
  Tom

SAS Super FREQ
Posts: 8,719

Re: SAS Enterprise guide limitations?

Hi:

  I find EG is wonderful for developing Stored Processes and production reports -- the prompts that you build in EG can automatically get converted to Stored Process (SP) prompts. You can build conditional logic into your EG generated code very easily through the use of selection groups for Stored Processes. And what I like most of all, when you are working with "legacy" code and turning that code into a Stored Process, you can get EG's Stored Process Wizard to scan through the code for macro variables, which shows you exactly what macro variables are good candidates to become prompts.

  If you start from a project, you can turn a whole project into a Stored Process; or, you can turn just a task into a Stored Process. You can develop, register and test your code on the BI Platform from within EG. That is great! You can use DI Studio to make your jobs that need to run to populate the production tables/data marts; but for developing projects/tasks/Stored Processes that will be used for reporting -- especially if the reports need to be generated based on prompt values, then EG is great for development (in my opinion).

  The beauty of EG is that it works in point and click mode for the users who don't want to write code -- and then their code can be used as the basis for stored processes and it works in "programming" mode, for the users/programmers who do want to write code or who have code to turn into production reports/stored processes.

cynthia

☑ This topic is SOLVED.

Need further help from the community? Please ask a new question.

Discussion stats
  • 6 replies
  • 605 views
  • 3 likes
  • 5 in conversation