About AllanBowe

AllanBowe · ‎06-17-2024

This is a native feature in Data Controller for SAS, and available in the community (free) version Go to View / Lineage / choose library / choose table / choose column (optional) and you get a full impact analysis (jobs and tables in png / svg / csv formats) https://docs.datacontroller.io/videos/#data-lineage https://git.datacontroller.io/dc/dc/releases

AllanBowe · ‎10-16-2023

actually, there is a way you can still keep your web app contained in your SAS code, and stream everything through WEBOUT, and comply with CSP We manage it with Data Controller - one SAS program (demostream_sas9.sas) deploys the entire app: https://git.datacontroller.io/dc/dc/releases An overview of the technique is described here: http://sasapps.io/sas-streamed-apps

AllanBowe · ‎10-16-2023

The option you describe (putting the web content on the web server) is in fact, the correct approach to take. Mixing HTML/CSS/JS/IMG/ICO/WOFF etc into DATA STEP and PROC STREAM is a very hacky / hard to maintain & extend way to build (non trivial) web apps. The option you are probably looking for, would be to modify the CSP policy in the web server directly. You cannot change CSP policy from SAS code, nor from the content (or headers) of the WEBOUT destination. More info here: https://sasjs.io/security/#content-security-policy

AllanBowe · ‎10-06-2023

You can stream web files using STPs so long as you set the http headers, eg using a macro similar to this one: https://core.sasjs.io/mp__streamfile_8sas.html In general though it's not a recommended approach. You will have the overhead of a SAS session for every asset (html, css, js files etc) plus the challenge of writing code to deal with situations such as very wide lines of text, binary files (images), different encodings etc. You would be far better off just using a web server to serve your web content, and calling your SAS services as needed using JS. If you don't have SAS 9 EBI, or SAS Viya, you could try out SASjs Server as an alternative: https://server.sasjs.io The advantage of following the SASjs Server approach is that (so long as you use the SASjs framework) you will be able to easily migrate to Viya at a later date.

AllanBowe · ‎09-04-2023

@YuryShkoda found the issue Seems the "arguments" attribute is no longer supported on the compute API side We use it as our payload is also used for executing Jobs as well as arbitrary code. Solution is simply to remove that object from the request Body.

AllanBowe · ‎09-04-2023

This thread is in relation to this ticket: https://github.com/sasjs/adapter/issues/829 Looking for support here whilst we figure out the root cause (maybe someone is already aware). It looks like something has changed recently on Viya 4 when it comes to running code in an existing session. This is the request / response (running SASjs CLI with verbose mode): ℹ HTTP Request: POST /compute/sessions/ca3f4bdf-3cf8-48b5-91fb-f9f11999789c-ses0000/jobs HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJhbGciOiJSUzI1NiIsIREDACTED User-Agent: axios/0.27.2 Content-Length: 1162 Host: extviya4.emea.sas.com Connection: close { name: 'myJob', description: 'Powered by SASjs', code: [ 'data work.demo;', ' do x=1 to 1e6;', ' y=ranuni(0);', ' end;', 'run;' ], variables: { SYS_JES_JOB_URI: '', _program: '/Viyademo08 Group Folder/4GL/proj/yurshk/jobs/long/long', _DEBUG: 131 }, arguments: { _contextName: 'SAS Job Execution compute context', _OMITJSONLISTING: true, _OMITJSONLOG: true, _OMITSESSIONRESULTS: false, _OMITTEXTLISTING: true, _OMITTEXTLOG: false } } HTTP Response Code: 400 HTTP Response: Date: Fri, 01 Sep 2023 15:14:27 GMT Content-Type: application/vnd.sas.error+json;charset=utf-8;version=2 Content-Length: 470 Connection: close Set-Cookie: sas-ingress-nginx=9a59cdfa1a238157REDACTED; Path=/compute/; Secure; HttpOnly; SameSite=Lax Cache-Control: no-cache, no-store, max-age=0, must-revalidate Content-Security-Policy: default-src 'self'; object-src 'none'; frame-ancestors 'self'; form-action 'self'; Expires: 0 Pragma: no-cache Sas-Service-Response-Flag: true Vary: Origin X-Content-Type-Options: nosniff X-Xss-Protection: 1; mode=block Strict-Transport-Security: max-age=63072000; includeSubDomains { version: 2, httpStatusCode: 400, errorCode: 5036, message: 'The input provided for this request is not valid for this endpoint. ', details: [ 'path: /compute/sessions/ca3f4bdf-3cf8-48b5-91fb-f9f11999789c-ses0000/jobs', 'correlator: d03057f5-3c73-4a2c-b171-af28f8367024' ], remediation: 'Check to make sure the request made to the server is a valid request. Contact your system administrator to determine if the request made from your application is formatted correctly.' } Checking the API docs the example body does appear to be different however it does not correspond to the referred JobRequest schema. Does anyone have any working examples, or can see what is wrong with our payload? It has worked fine for several years until now..

AllanBowe · ‎09-01-2023

Great to chat, we're on the case in relation to the root cause, the issue can be tracked here: https://github.com/sasjs/adapter/issues/829

AllanBowe · ‎09-01-2023

Interesting. This code is not within SASjs either. Perhaps we can schedule a call to take a look? I'd be happy to help, if I can. https://4gl.io/cal Am also free for the rest of today if you want to send me a PM.

AllanBowe · ‎08-31-2023

Have you considered just using Data Controller for SAS? https://datacontroller.io We recently changed the pricing, so it is now free for unlimited users: https://datacontroller.io/pricing Would be happy to shadow a deployment. Thanks to our OEM licence of the HandsOnTable grid system, it can handle on-page editing of several thousand rows (per data page), even hundreds of columns. For excel uploads, it can be tens of thousands, or more if you have a powerful PC. For CSV uploads there is no limit, as the processing is done backend in SAS. We have multiple customer references, including banks / government / insurance if needed. The source is also available, you can build it yourself - https://git.datacontroller.io

AllanBowe · ‎08-31-2023

Mixing HTML / JS code with SAS is an antipattern - I would not recommend it, for many reasons: Your app now requires developers with TWO skillsets (SAS + Web) to maintain. These guys are like unicorns, very rarely are they competent in both disciplines. You cannot test your web / sas code in isolation You cannot lint either your SAS code nor web code using regular IDEs You are reliant on a SAS instance to work on the web component You cannot build a complex application this way (because even a very simple app will rapidly get complex) Good luck using React, Angular, or any modern frontend framework that requires compilation. (By the way, it's not impossible, you can do this with SASjs Streamed apps) When we built the JES API approach (documented here: https://adapter.sasjs.io/#using-the-jes-api ) it was not possible to re-use session ids, perhaps that has changed now, if so I hope that this thread will be updated. To my understanding though your performance gains will be limited to the use of a re-usable compute context - meaning best case 2 seconds on Viya 3.5 and 6-8 seconds on Viya 4. Contrast with Compute API which is ~1 second - https://adapter.sasjs.io/#using-the-compute-api

AllanBowe · ‎08-24-2023

That's pretty much what the SASjs CLI does (although it starts by polling fast, then polls more slowly). Thanks for sharing your solution!

AllanBowe · ‎08-16-2023

You just need to send those data values back to the _webout fileref in JSON format. This macro can help: https://core.sasjs.io/mm__webout_8sas.html Here is a seed app in react that does exactly as you describe: https://github.com/sasjs/react-seed-app/ You could also deploy our data management SAS app, free for unlimited users, but written in angular, that has many such examples: https://datacontroller.io

AllanBowe · ‎08-15-2023

That's right, SASjs uses a 'session array' and spawns additional sessions as they are popped off. It also kills the sessions after they are used, which is more efficient than leaving it running for 15 minutes. If you want to to re-use a single session you just need to post to the `/compute/sessions /$sessionid/jobs ` endpoint, eg: https://github.com/sasjs/adapter/blob/master/src/api/viya/executeScript.ts#L157

AllanBowe · ‎08-15-2023

My theory on this is that the reusable context "reuses" a (parent) SAS session for each of the "sas00xx" (child) sessions. That parent session will have already run the autoexec, and have the options set, making the creation of each child session much faster. The reason you are seeing new session ids is likely because you are creating new sessions with each request (expensive / still quite slow). If you want to re-use a specific session, you need to connect to that particular session id (they last 15 minutes without activity by default). Connecting to an existing session is much faster than creating one each time - which is why, in the SASjs Adapter, we pre-spawn sessions for subsequent use (providing sub-second response time if everything is set up correctly).

AllanBowe · ‎06-21-2023

bom dia! A SASjs é suportada pela minha equipa e por mim, e temos clientes/casos de sucesso em vários continentes. Se precisar de suporte com SASjs também pode entrar em contato direto com nossa equipe no canal Matrix: https://matrix.to/#/#sasjs:4gl.io Se outras pessoas compartilhassem suas experiências de SASjs aqui, isso também seria fantástico.