Desktop productivity for business analysts and programmers

First SAS project, email alerts about subscription issues

Reply
Frequent Contributor
Posts: 90

First SAS project, email alerts about subscription issues

Hello,

I've recently been assigned my first little SAS project. Because of my limited experience, and because there's so many ways to solve SAS projects, I'd greatly appreciate some preliminary advice so that I can start moving in the right direction straight away.

I have access to Enterprise Guide, DI Studio, and a single SAS data set that contains all the data I need. The SAS data set contains data on various types of alerts about customer subscriptions, such as whether the subscription is close to expiring, whether the subscription fee is overdue, etc. The data set also contains basic information about the customer associated with the alert, and about the consultant/salesperson responsible for the customer.

My program is supposed to read through the customer subscription alerts, then extract & group them based on what consultant/salesperson the customer is assigned to. The program should then send each consultant/salesperson an email report about this, so that he/she knows which customer he/she needs to follow-up. The program should check for alerts and send out emails on a daily basis.

I'd deeply appreciate any guidance on how to do this most efficiently. In example, I don't know whether it'd be most efficient to use PROC SQL or a DATA step to extract information from the SAS data set, and I'm particularly curious about the most efficient way to generate and send out emails. I imagine macros will be very vital to this kind of program.

In any case, thanks for your time.

PROC Star
Posts: 1,146

Re: First SAS project, email alerts about subscription issues

I have a very strong opinion on this. As a new user, you'll find it easiest to use Enterprise Guide. In a new EG project, bring in your SAS dataset, and then use the Query Builder to do your extracting and grouping (it uses PROC SQL in the background). There is a "send email" task in EG, so depending on how complex your requirements are, you may be able to do the whole thing with very little fuss. You can then use the ability to schedule your EG project to run it daily.

Be careful about macros; they aren't the same thing in SAS that they are in other products. In SAS, they are incredibly powerful, but can be very difficult to understand and use.

As you figure out exactly what you're trying to do, feel free to post more questions!

Tom

Frequent Contributor
Posts: 90

Re: First SAS project, email alerts about subscription issues

Thank you very much TomKari!

I have a quick follow-up question about EG.

If I start an EG project and use the built-in functions, I quickly end up with dozens of different task objects and fragmented code, such as the Query Builder object which contains code that's stored separate from my initial program. Would it be considered "best practice" to continuously insert all the generated code into my initial program so that task objects can be deleted after having served their code-generating purpose? I guess what I'm asking is: would it seem most professional to the customer (who has some technical SAS expertise) if I give them a single program file, or if I give them a project file filled with various task objects? What would you assume they expect?

Thanks again.

PROC Star
Posts: 1,146

Re: First SAS project, email alerts about subscription issues

SASKiwi's answer is completely correct; I'll just add a couple of comments.

Since you mentioned that you have access to Enterprise Guide, I'm assuming that your client is comfortable with it. In that case, setting up EG so that the components (code, results, log...) generated by the tasks will be kept within the project leads to a nice, clean project file to deliver to the client...everything is saved within the project, except for the actual SAS datasets, which are represented by links. Therefore no data exposure concerns. I think you'll find over time that the EG representation of an ordered list of tasks leading to results is a nice way to represent the code (I note from your comment that you find it a little disorganized looking at this point!)

I agree absolutely that for reliable, production-grade scheduling of a job using the EG scheduler is not the best solution. In that case, you should definitely export the SAS code and use one of the server-based options.

And of course, with SAS, there are ten ways to do anything, but these should get you started.

Have fun!

Tom

Super User
Posts: 3,235

Re: First SAS project, email alerts about subscription issues

I think you need to ask the customer how do they prefer to run this SAS job. There are many different ways SAS programs can be run and how you organise those programs depends on how you are going to run them.

For example, if the customer is happy to run the SAS job manually from EG on a desktop then providing them with an EG project is entirely appropriate. You can also schedule an EG project to run at particular times in EG, but remember the desktop must be on and be able to connect to the SAS server for the scheduling to work.

If this SAS job needs to be scheduled more reliably, then scheduling it to run on the SAS server is a better option, but in this case the entire EG project needs to be exported into SAS program file(s) and it is the starting program file that is scheduled.

Ask a Question
Discussion stats
  • 4 replies
  • 306 views
  • 8 likes
  • 3 in conversation