@dobby  - I suggest you try getting a LIBNAME working first. I'd also suggest trying the DSN-less approach and put everything in your connection string. Here is an example of what we do: libname sqlsrvr odbc noprompt = "server=MyServerName;DRIVER=SQL Server;Trusted Connection=yes;" qualifier = "MyDatabase" schema = "MySchema"; All you need to do is replace MyServerName, MyDatabase and MySchema with yours. Once you get the LIBNAME working, you copy and paste the connection string into the Management Console Server connection properties. Please note the use of Windows Authentication (Trusted Connection=yes) to avoid supplying a userid and password. I hope this is how your SQL Server is set up. ... View more

Hi @Mark_sas , thanks for the answer. I've tried already to start the deployment wizard, but in the products options for sas or related sas software there is no entry for "Operating System Services Scheduling" or anything similar. Do you know where is located to perform the installation from the wizard? ... View more

Nope, @ccaulkins912 ! Although it would be quite nice 🙂 ... View more

Correct licence renewal can be easily checked on Windows SAS metadata and app servers by remotely logging onto them and typing sas on a command line or the "Run" window. If a licence error window pops up then the licence has not been applied correctly. Remember both the SAS metadata server and app server need to have licenses applied. ... View more

It will not fail as you treat every row as a separate document.   IMHO, you have two options here:   1) You loop over every record (I would use macro for that) and use the XML engine to parse out each individual value as a seperate document and append that to a target table. 2) "Stitch" all the individual values by adding some XML up front and at the end. I would need to know your XML data to figure out how that would look like.   The macro approach for option 1 is moderately advanced but it would be a great learning experience.   Look on the web for macro processing of every row in a table. It encompasses creating a macro that processes a single XML string where that string is a variable. Than, using a datastep to go through the source table, use call execute() to call that macro for every row.   SAS macro's are very powerful. Allow yourself the satisfaction of learning to use them for your specific use case. It will be very gratifying I promise.   Hope this helps, -- Jan.     ... View more

I've restarted the SAS Servers and now it is working fine. Thank you very much! ... View more

Hello,   Your json body does not appear to be malformed. By I did notice this:   HTTP content type: applicatio/json   Perhaps changing applicatio/json to application/json might resolve issue? ... View more

I've been dabbling with this, and hit the fundemantal issue that JSON is inherently schema-less, unlike XML. Essentially, you are never sure what you're going to get, in terms of field structure, from any one REST call (or another expression of data in JSON, like an "export to file").   What I tried was creating "template" datasets/tables, that I could use to conform any instance of JSON derived tables (from the same source or endpoint) to the virtual schema that the data (more or less) complies with.    So in the code I was working on, once I've got the various tables - but often only one really - back from the JSON library, I run them through an append to an empty "target instance" of the template dataset, freshly created for the purpose of being the output from my user transform, which means that I get an output table from my call to the REST end point that's crudely conformed to a static structure/schema.   I ended up with a User Transfrom that took the "template" dataset as an input, and the REST endpoint details and options/parameters as options, and coughed out a dataset with a fixed format. So in DIS, I could use registered tables as the output of the UT that called hte REST endpoint, with a stable data structure.   PROC APPEND is a but low-tech/brute force for doing this, it would probably be better done in a more in-depth macro. There are options to suppress the squawking about the JSON sourced table not being just like the template derived BASE, but I couldn't get it to stop issuing warnings, and "probably beneign warnings" are absolutely not what want in a DIS UT.   XML is much prefereable, as the XML Map mechanism, and XML itself, tackles the issue of how to handle parts of a schema not being present in a particular set of records - in JSON the absence of a schema, and the absence of any sort of placeholder for "not present" data items/fields, means that it's actually an undesireable format for "ETL-esque" data transport, but it's not going away. ... View more

Excellent, and this install contained the SAS DI software? If it did not, you can also install it separately on Install SAS FOundation and clients.   If you already have it, the last bit you need is to create a login profile in SAS DI, and have that user in the SAS metadata (server) ... View more