EG task "Upload to LASR" useless?

[bheinsius]

Hi,

EG71 provides an Upload to LASR task.

Prerequisite for this is that the LASR server is configured in the same metadata environment as EG.

However, Dutch SAS TLM consultants advice against integrating VA in a SAS BI metadata environment, they advice to install VA with its own metadata environment.

I validated this with developers at SASGF15 and they say the same.

Does this render the Upload to LASR task useless?

Bart Heinsius

[LinusH]

Given this advice - yes!

SAS in Sweden does from what I understand advice against a shared metadata. They were however skeptical in previous releases.

For me to promote VA as a BI application, it really have to be on a shared metadata environment. Without it, it's not integrated. And not integrated, you loss the benefits of end-to-end SAS product line.

[CaseySmith]

The "Upload to LASR" task in EG and AMO is a very useful task for getting data prep/output from EG and AMO processing into LASR Analytic Server and registered for use in Visual Analytics.  However, as Linus pointed out, if you choose to maintain separate metadata environments, you are defeating the integration that task provides.

You might be able to define a LASR library in the BI metadata environment, then use the Upload to LASR task to upload to that library.  The data would get loaded into LASR, but the table would not be registered in the VA metadata environment, thus couldn't be automatically used in VA.

[bheinsius]

if you choose to maintain separate metadata environments, you are defeating the integration that task provides.

it looks like i don't really have a choice, since SAS Institute advises against it.

You might be able to define a LASR library in the BI metadata environment, then use the Upload to LASR task to upload to that library.  The data would get loaded into LASR, but the table would not be registered in the VA metadata environment, thus couldn't be automatically used in VA.

i don't completely understand your idea, can you elaborate on this?

[CaseySmith]

You might be able to define a LASR library in the BI metadata environment, then use the Upload to LASR task to upload to that library.  The data would get loaded into LASR, but the table would not be registered in the VA metadata environment, thus couldn't be automatically used in VA.
i don't completely understand your idea, can you elaborate on this? 

I haven't tried it, but given separate BI and VA metadata servers, I would think you could define a LASR library in your BI metadata server, so you have an output destination for the Upload to LASR task (when EG or AMO connected to the BI metadata server).  When you run the Upload to LASR task and "upload" to that LASR library, the data should get written (loaded into memory) to the LASR server (so you could use IMSTAT for example).  However, the uploaded table would not get registered in the VA metadata server, thus not automatically available for use in VA, losing a large benefit of the Upload to LASR task.

If your goal is to use the data in VA and you have separate metadata environments, probably easier writing the data to a location that can be accessed by both environments, then using the VA tools to load the data.

[bheinsius]

If your goal is to use the data in VA and you have separate metadata environments, probably easier writing the data to a location that can be accessed by both environments, then using the VA tools to load the data.

that is indeed my goal, so that renders the EG task "Upload to LASR" useless.

[JuanS_OCS]

Hi Bart,

not always: SAS is supplying more and more SAS VA (SAS VAAR, actually) with most of the SAS Solutions, of not all.

This means that:

- if you have the full SAS VA as independent solution, indeed, it is better (just a suggestion, based on good architecture sinergies, which I understand you are aware of at this moment). And it makes sense, as principal solution for the Front End/Reporting. 

- if you have a different SAS Solution, then you get the license for SAS VAAR, then you will have a restricted version of SAS VA, but you get a Shared Metadata, then the functionality on EG makes also full sense.

[SASKiwi]

I understand the main reason why SAS recommend a separate VA environment (separate metadata server) is that SAS VA is on a different upgrade cycle to SAS BI. VA version/maintenance upgrades tend to be 6-monthly and SAS BI maintenance upgrades are usually yearly.

We are just starting a SAS VA install project and this issue of shared or separate metadata servers was one of the first decisions to make. I would have preferred a shared metadata server setup for the very reasons discussed here, but that required a maintenance upgrade for our existing SAS BI setup from SAS 9.4 M2 to M3. You wouldn't think a maintenance upgrade is a big deal but SAS quoted 11 days work to do this to both our Production and DR environments (5.5 days each)! So another reason to keep your SAS VA environment separate is it is too much work, too disruptive, and too expensive to apply maintenance to SAS BI 9.4 to keep it in synch with VA.

I have heard that this maintenance issue will be addressed in the next major SAS release to be publicised soon at 2016 SAS Global Forum - I await the details with interest.

[JuanS_OCS]

Indeed, dependencies and impact on maintenances is an issue.

I am looking forward to hearing the incoming improvements on this matter by developers at the SGF!

[LinusH]

Until SAS recommends a shared environment I consider VA an immature product.
Let's hope for the next version...

[SASKiwi]

I am told that the goal in the next release is to reduce the time to do maintenance upgrades from days to hours. The reason for the long time is the SAS mid-tier needs to be completely redeployed and retested.

If this does indeed happen then I can't think of any major technical reason to keep SAS VA separate.