topic Re: Client/server work flow(b/w EG and App server) in SAS Enterprise Guide

Client/server work flow(b/w EG and App server)

sasprofile — Thu, 30 Oct 2014 18:52:59 GMT

Hi all,

I have a doubt.please can any one clarify my doubt.I would really appreciate your help alot.

When a user runs runs a code or submits a job from Enterprise guide/DI on SAS Application server where exactly the request goes first and how the entire process works till the user receives the result from the server.and what are the different servers involved in this whole process and what exactly each server do ? please can you explain this workflow, i mean the step by step process till the EG receives the reply from server.

and what exactly work space sever will do and what will the stored process server do ?

everyone is asking me these questions am not able to answer anything perfectly.If am giving book definitions they are not satisfying with my answers.please help me,it would be a big favour to me.

what are the main differences between 9.2/9.3/9.4

Re: Client/server work flow(b/w EG and App server)

Community_Help — Thu, 30 Oct 2014 19:15:13 GMT

Hi there - thank you for joining the community and posting a question!

I saw that you had duplicates of the same question in different communities - I removed the duplicates and you should get an answer soon in this community. Thanks!

Re: Client/server work flow(b/w EG and App server)

Kurt_Bremser — Fri, 31 Oct 2014 12:48:26 GMT

When Enterprise Guide starts, it uses a metadata profile (credentials are stored in the profile or the user is prompted) to connect to a metadata server. It then receives a list of workspace servers that can be used. Once a WS is needed (to run a job/query or to get a list of libraries etc), EG checks if it is the same physical server that runs the metadata server (if yes, use the credentials from the metadata connection, if no, either use creds from the last session or prompt for new), then connects to an object spawner on the physical server that is in the definition of the WS. The object spawner starts a WS process and hands off connection to that.

The Query/job is sent to the WS in the form of SAS code. The WS processes this and then sends results back, which EG will display immediately or on request (depending on settings).

Workspace Servers usually (unless pooled) run under the requesting user's context.

The stored process server is a single SAS instance that runs under a special account (usually sassrv) and allows the execution of predefined SAS codes according to their definition in the metadata. It can be used by SAS clients (EG, for instance) and has a web-based frontend run by jboss that manages access to the stored processes via browser/http.

Re: Client/server work flow(b/w EG and App server)

sasprofile — Fri, 31 Oct 2014 13:36:34 GMT

Thank you KurtBremser for your prompt reply,I really appreciate it.

but am very sorry,still its not clear to me.

from where EG will receive the list of workspace servers.there would be only one workspace server right.

my question is when a user a submits a submits a program from EG after connecting to server.

where exactly the request will go,which one will come first into picture and how the object spawner,workspace server and stored process server will be helpful in this whole process till the user receives the response.

Re: Client/server work flow(b/w EG and App server)

jakarman — Fri, 31 Oct 2014 16:16:52 GMT

Start with seeing EGuide as some thin client somewhat smarter als the old 3270 terminal emulator or browser but it is functioning similar like a front-end tool.

The real data-processing is needing some server (service) to run that.

The types of servers/services are:

1- A local on the desktop installed SAS Base/Foundation that Eguide is abel to see/recognize

2- An by an integration-technologies managed daemon (Object-spawner) dat will start users sessions that are based on Base/Foundation

This can be seen as a workspaceserver.

3- A Metadata server controlled environment that is supporting several types of SAS servers(services), those are:

+ user based (workspace server) running Base/Foundation

This is almost similar to the integration-technologies approach.

+ shared group account (stored process server) as Base/Foundation

+ web-based (Portal) controlled using a shared group account (pooled workspace servers) as Base/Foundation. It is the midtier being another central point.

+ (many more) Batch grid connect Olap

SAS Solutions are build on top of this (DI/BI) structure of metadata bases ad

Tools like DI (Data integration Studio for ETL), Information maps and more are additional ones.

The use of shared group account is one to be carefully reviewed. Shared group accounts is an approach that is to be avoided mentioned as action by a lot of regulations where auditability and traceability are important on classified data. IT tool suppliers are often ignoring this and showing the quick nice paintings as the result of their tools.

It is dependent on each situation how the identification/authentication is going and handled.

ad 1/ (local desktop) identification and authentication is not applicable. All is done by Windows at OS level.

ad 2/ (integration-tech) identification and authentication is done by the OS of the server that is running that Base/Foundation.

ad 3/ (metadata workspace server) The Eguide users are facing manay services,

+ They are connecting to the metadataserver and being identified and authenticated on that dedicated SAS service. When succesfull

+ An OS process is started that is needed to run by an identified users and getting authenticated (like inttech).

The way to achieve this can differ from some technical aspects. In the most simple approach ist a login and password giving tot that OS process.

What you will see that the user/password can be found cached on a lot places. In config-files (high prov accoutns) in user-profiles and in the SAS metadata (database)

The role of the metadata database is like a IDD Integrated Data Dictionary Metadata - Wikipedia, the free encyclopedia Talk:Data dictionary - Wikipedia, the free encyclopedia

It can contain technical descritions (Servers/services), Business strcutures and logic and the whos is allowed to do what (security).

The most easy way using Eguide is connecting it to technical component like a workspace server. Adding business logic to that is making is more usefull but also more complicated to understand.

Re: Client/server work flow(b/w EG and App server)

sasprofile — Fri, 31 Oct 2014 16:48:17 GMT

Thank you so much Jaap Karman for your response,I appreciate it

Re: Client/server work flow(b/w EG and App server)

jakarman — Fri, 31 Oct 2014 17:03:41 GMT

This was already a long post, if you have that and could explain to others than you can go to Eguide usage in more details. Then only the focus on metadata- workspace server usage.

Are you ready for that?

Re: Client/server work flow(b/w EG and App server)

Kurt_Bremser — Mon, 03 Nov 2014 06:36:35 GMT

As I already told you,

connect to a metadata server. It then receives a list of workspace servers that can be used.

There can be any number of workspace servers on any number of physical servers. The primary workspace server (which new project steps are automatically assigned to) is also defined in the metadata profile (Tools - Options - Administration - Connections - Server). Depending on the metadata, a user can have any number of workspace servers on any number of physical servers in his server list.

Every physical server that hosts workspace/stored process servers needs to have an Object Spawner running, so that clients can request a server for connecting to (workspace servers are ususally started on demand, other servers may already be started)

The flow looks like that:

New step in Process Flow - EG assigns primary WS (user can manually assign another one)

Step is executed - EG checks if connection to assigned server is already up, if not, contact the object spawner on the physical server to request a server instance/connection

Code is sent to server

Server executes code

Results are sent to EG

EG displays results, according to settings

Re: Client/server work flow(b/w EG and App server)

jakarman — Mon, 03 Nov 2014 19:48:50 GMT

So we have the basics (1), by kurt the normal processing (2), than there is an additional part data integration (3)

Data integration is the part causing a lot of confusion as it looks to the unaware person like the tool is different as described in (1) en (2).

There is a filetransfer in the tool you can drag and drop using files from windows to the file folder tabs.

The processing as SAS code is done at the server side, but you can access odbc excel outlook and other Windows datatypes.

What is happening there?

The data readed into a SAS datastep and in-stream data using the datalines approach.this can be uploaded to the SAS server and executed there.

There are some more dedicated Windows features but the principles of (1) and (2) are kept valid.

Re: Client/server work flow(b/w EG and App server)

sasprofile — Tue, 04 Nov 2014 01:02:16 GMT

KurtBremser,

Thank you so much for your response,I really appreciate it.

according to your explanation below is what I understood

When I start EG or DI it will initially connect to thr metadata server. The metadata server knows who the users are, where the data resides, and how to connect to SAS workspace servers and SAS Stored Process servers.

When you hit the submit button in a project or job from EG or DI, the EG or DI is going to connect to an Object Spawner (daemon) to launch a SAS workspace wherein my SAS code is executed. Stored Process server is not involved. SAS metadata server is only involved in checking permissions and helping the client application find its object spawner.

but my question is in this whole process does stored process involvement will be there or it has nothing to do with this process ?

Re: Client/server work flow(b/w EG and App server)

Kurt_Bremser — Tue, 04 Nov 2014 06:44:17 GMT

It is of course possible to involve the stored process server when doing work with EG. Most of the time, one will create stored process with EG, and stored processes can be added to a project from the SAS Folders.

But access to datasets, queries, user written codes or procedure steps in the EG project will usually use a workspace server.

Stored processes are most useful when used with the web interface to permit users access to SAS without actually doing any SAS work.

Re: Client/server work flow(b/w EG and App server)

RamKumar — Tue, 04 Nov 2014 12:42:53 GMT

Where can we see the object spawner? e.g. server

As per SAS(R) 9.2 Intelligence Platform: Application Server Administration Guide, object spawner is used for for accessing the SAS Metadata Server. How it plays a role for accessing the workspace server?

Re: Client/server work flow(b/w EG and App server)

Kurt_Bremser — Tue, 04 Nov 2014 12:49:57 GMT

I think you completely misinterpreted the graph, read the text.

The object spawner contacts the metadata server for information about the servers it is responsible for (IP ports, startup scripts).

The metadata server is always contacted directly by the clients.

Re: Client/server work flow(b/w EG and App server)

sasprofile — Tue, 04 Nov 2014 18:52:58 GMT

Thank you so much for all your prompt responses,I appreciate it.

can you please answer my below questions,i would really appreciate for a quicker response from you.

1)How the performance tuning can be done,are there any different ways to do performance tuning.

2)Can you explain What is the Architecture level difference between SAS 9.3 & SAS 9.4 ?

and also features differences between 92/9/3/9.4 ?

3)Can you explain the process we need to follow to migrate from 9.3 to 9.4

can you explain how we should handle SAS environment the migration process,what are the different things we should do?

4)can you please explain me what are the activities involved before we are going for up gradation,we need to do some prerequisites for the migration activity,can you please explain what are prerequisites required for base sas 9.4.

am asking Hardware level and software level prerequisites ?

5)What are the different ways of deployment,there are two levels of deployment right,different ways of Migration ?

Re: Client/server work flow(b/w EG and App server)

jakarman — Tue, 04 Nov 2014 19:00:55 GMT

The role of the objectspawner...

That process is starting all those subprocesses and does a user context switch. Workspaces (pooled/standard) and de Stored process servers.

To be able to do that the object spawner is needing all that information from the metadata-server. It will read that information when that object spawner process is started. That Includes the scritps ports userid-s and password-s. The user-ids/passwords are needed as shared/group accounts for the SP and pooled-WS.

These keys/passwords can be found/set at the general servers tab in the SAS-metadata (SMC). This process of reading the metadataserver can be found in the metdataserver log. When more information is visible you can see the requests for users/passwords scripts.

When you have made errors in the metadata this information cannot be read anymore at startup. Your service will be down.

When the metadata server is not ready to handle requests for the objectspawner. The objectspawner may start but starting the services will fail.

The object spawner is connecting to the metadataserver there os text-configfile having the sastrust key being defined (and pswd) so it can connect (and do everything sastrust is allow to do).

When processes are running the objectspawner and metadataserver may be restarted without disturbing those running processes.

As a pitty in Unix it are dependent processes of the objectspawner, with thatl dependency they are going down also with that one.

Stored process

As the are mentioned: there are several parts on those. 1/ The sas source 2/ the sas metadata conection to a sas server 3/ the executing by either a WS or SP one.

The stored process approach makes sense when there is a SDLC (software Development Life Cycle) with a DTAP (Develop Test Acceptance Production) segregation.

Having approved tested/validated code deployed to production you can accept the usage of a shared/group account with limited usage. (no code changed allowed, validated users).

A webbased is a good example. AMO and Eguide can also use SP's (sas-code / metadata) either run by a SP or WS.

SAS DI is a development tool (only WS) that can generate the sas-code to be used in a SP definition (sas code / metadata).

The same word SP is used in several different meaningsm pinpoint on the meaning what it is about with every action.

Re: Client/server work flow(b/w EG and App server)

jakarman — Tue, 04 Nov 2014 19:20:52 GMT

sasprofile,

1/ performance starts at the OS level. That is not SAS specific there is al lot about that.

Configuring hardware for SAS: what you should know before you install - SAS Users

2/ In the basic concepts 9.3 and 9.4 are not really different. They changed as lot as example the VM-tools and the SAS/secure bundling.

http://support.sas.com/documentation/cdl/en/whatsnew/64788/PDF/default/whatsnew.pdf

3/ Migration is described at Maintenance Releases and Product Upgrades All depends on what there is already running in the current situation

metadata based, solutions, batch grid or just only Foundation by terminal usage (like SAS studio).

4/ That inventarization is the fist thing needed to be done

Pre-req is sufficient SAS knowledge to ask for the needed things (chicken/egg problem what is first)

5/ There are many ways of deployments (multi tier) all is dependent on the target environments and their req-s.

It is not unusual to be faced by the need for repackaging the installation. leaving the SDW to be used on a isolated first machine that will become the source-image.

There are two stages in this that ins the installation and that gets being followed by the configuration. The configuration can need a lot of attention when there are business requirements and policies that are having conflicts with the SAS default approach.

Pre-req is sufficient SAS and business and applicable policies knowledge to ask for the needed things (chicken/egg problem what is first)

It looks to me you are uncertain on 4 and 5.

Re: Client/server work flow(b/w EG and App server)

SASKiwi — Tue, 04 Nov 2014 20:01:12 GMT

Regarding migration, your best approach is to read and investigate the SAS Support migration resources: Migration

Then if you have any questions remaining to post them. Migration is such a large topic that putting a few "sound bites" in a post isn't going to cut it.

Also your migration strategy is highly dependent on your current SAS environment and what you are planning for your new SAS 9.4 deployment. Since we know very little of either of these we can't offer you any more than a few helpful hints.

FYI, we are in the middle of our own 9.3 to 9.4 migration. Be prepared for a project lasting several months is all I can say. Since our SAS 9.3 is running mission-critical applications, we decided to build a completely separate set of servers for SAS 9.4 so we could migrate and test with both versions running separately and in parallel. If you are not running mission-critcal applications you might not want to go to this extent.

Our experience is that code changes have been necessary to cater for 9.3/9.4 differences but these are relatively minor. If it is critical that SAS 9.4 give you the same results as 9.3 then all your production applications need to be tested to see that they run cleanly and really do produce the same results.

Re: Client/server work flow(b/w EG and App server)

BStone — Thu, 06 Nov 2014 11:10:06 GMT

To be honest, I would consult your SAS Account Manager to clarify your questions.

The majority of answers are based on different SAS version which are different to one another, espeically when it comes to the process of executing, querying, etc. SAS 9.4 and Grid functionality will also play a big and different role in terms of processing, depending how your environment is set up.

SAS documentation is great for guidance, but I would start by replicating exactly what you are trying to see:

1. Enable additional logging

2. Replicate whatever process you need information on, make sure you take note of the User ID and times your open a SAS Application, execute a job, etc.

3. Go through the server logs based on the User ID and times you noted in point 2.

That's the beauty of SAS, there is not just 1 way of setting servers / processes up.

Re: Client/server work flow(b/w EG and App server)

sasprofile — Thu, 12 Feb 2015 13:57:49 GMT

Getting Data into SAS from Pivotal(HAWQ)

Hi all,

Please can anyone help me how to get data which is located in Pivotal(HAWQ) into SAS.

am using SAS 9.2 on solaris 5.10.

please give me step by step process to get data using SAS/ACCESS Interface to ODBC.

am completely new to this i dont know how to do this

I would really appreciate for all your help.

Thank you

Re: Client/server work flow(b/w EG and App server)

SASKiwi — Thu, 12 Feb 2015 23:12:17 GMT

You should really start a new discussion for a new topic.....

However here is a good starting point (page 42) assuming SAS/ACCESS Interface to ODBC is already installed and licensed and you have the Pivotal ODBC driver installed:

http://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/61994/PDF/default/config.pdf