#stored process

When it comes to talk about optimization and user-experience, philosophy and science meet in a gray area of mistery where time relativity becomes a major issue, a contradiction in terms which is usually called "the Interphone Paradox":

-Bzz... Hello my love... Bzzz... I'm downstairs, are you coming? -Bzz... Yeah, I'll be there in a minute.

Philosophers usually explain that with the legend of the wise janitor. Once upon a time in Naples there was a lawyer company. They had an issue: the lift was too slow and little. Replacing the old lazy lift with a modern one was far too complicated and expensive, and employees were  suffering. In a situation where science could not help, the wise janitor came with the right solution: let's put a mirror next to the lift entrance. Employees were pushing the lift button, then looking at the mirror, checking if the makeup was ok, tightening their ties, making sure the hickey they got the night before in the disco was not that evident and such. And it was like magic: they pushed the button and it was like the lift was taking no time to arrive.

Information technologies call it "progress bar", "loading wheel", "porn animated gif", that is some graphical trick telling the user "no, seriously: I'm really doing something...", rising the user expectations and making him confident that something good is about to happen.

Taking it down to SAS Visual Analytics and Stored Processes, the problem is about the STP execution flow: when entering the report, the STP is launched and an empty frame is displayed until execution is completed. No way to put a porn animated gif in it. Take this you wise stinky janitor! So, what if your STP is expected to take a lot of time to execute? A nice solution might be using two STPs instead of one (would you have ever had thought of it my poor janitor? MHUAHAUHAUHAUHAUHAUAHAUHAUHAUAHUAHUAHAUHAUHAUHA).

First thing you have to do is about creating a "Launcher" STP, containing just the loading wheel and a hidden iframe pointing the "Core" STP. Then, you add a javascript callback on the iframe loading completion event, hiding the wheel and showing the iframe. This way the flow is completely asynchronous: the launcher STP is shown immediately, for it takes almost no time to load the gif. The core STP has no relation with the rest of the GUI, so Visual Analytics won't bother making you waiting, and the launcher is the only responsible for the output to be displayed.

How do I execute the core STP? You just need to have your iframe src referencing the SAS Stored Process Web Application, which is usually bundled with the SAS Web infrastructure Platform you get with Visual Analytics.

How do I pass prompt parameters from the launcher STP to the core STP? Simply by passing the core stp the same query string as the one for the launcher (except the _program parameter, that is the STP to be executed).

How do I accept being smarter than the janitor? There is no way: you are just far too cool, that's all.

One of the  most underestimated controls in Visual Analytics Report Designer is Stored Process Control. Probably, this is more of a psychological bias, some kind of deep fear in post-SAS-9.1.3 users souls: what is an STP for in a Visual Reporting Tool? Why should I run some kind of SAS code when the GUI is already doing everything I need? Should we really awake and unleash the ancient demons resting behind the execution of plain user written SAS code?

They say the Dark Side of the Force is evil, but they don’t tell you about freebies. Just think of your nastiest end user accessing a troublesome report. Wouldn’t Darth Vader use the Force to fill the user mailbox with porn spam right in that moment, misleading him and taking his attention away from the report? Just embed in your report an STP using proc http to call youPorn APIs and the job is done.

The light side of the Force benefits as well from STPs. Main uses comprehends tricky layouts, advanced functionalities, LASR server management, and filling browsers with furry chubby heart-shaped-eyed pets.

On one hand, by using STPs you can show in a frame any kind of output. It doesn’t just mean you can show a number you wouldn’t be able to show in a table. It means you can have the STP writing out your own HTML output, including images, advanced css, javascript interactions, you can even include external js libraries such as jquery. It means having a real web application inside your report, providing advanced functionalities, including external content, calling other STPs, handling advanced side effects.

On the other hand, you can have the STP managing the LASR sword. Err…  I was meaning LASR server, of course. An STP natively has the capability to present the user with prompts. By asking the user which kind of data he is going to use, you can have LASR specific procedures such as proc imstat to dynamically load in-memory just the tailored portion of data that is needed, maybe setting constraints on the number of rows you are going to load, resulting in dramatic performance boosts when you deal with huge amounts of data being held on unfit architectures. By the end of the story, you have the elephant getting into the matchbox. One bit at a time. Jabba the Hut would approve.

  “Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering. Suffering leads to STP.”