You could try setting the loggers App.tk.eam.ssl and App.tk.els.ssl to trace to see if this surfaces more information on the TLS communication, you may wish to engage SAS Technical Support for help. ... View more

I don't think your described use case is part of the purpose of a group-managed service account, so I wouldn't expect such a feature to be added. If you want multiple users to be able to edit the code you'd want to store the code (the .sas file) in a place where those individual users can edit it, rather than having them edit the code as the service account. When you use SAS Studio's "Deploy as Job" function, this creates a jobRequest and jobDefinition object, with the jobDefinition containing the code from the program you chose to deploy as a job, and the jobRequest referencing that jobDefinition. That job definition is not stored in SAS Content. The default rules allow non-administrators update permission only on jobDefinitions they created. The "Redeploy job" function would update that job definition with any changes to the code, so this could only be done by the user who originally deployed the job. If you don't use the Deploy as Job function and instead use the Create Job Definition function, this gives you the option to save the deployed job in a given path in SAS Content, so additional permissions can be conveyed based on the permissions set on the path in SAS Content where the job definition is saved. After doing this, you can use the "Schedule job" option on the job definition to create a job request linked to that job definition. In this workflow, because the jobDefinition is stored in SAS Content, permissions can be applied based on the storage location and other users could edit it if appropriate permissions are set there. ... View more

This message is saying that the TLS communication failed, but doesn't say why. We should look for additional messages for context, you may want to check the _console log files as this would capture any errors written to stderr/stdout that aren't captured in the dated service logs. Usually, TLS failures are the result of the certificate not matching the hostname or a lack of a chain of trust. Assuming the issue is one of those I would check the certificate you are providing in the SSLCERTLOC contains the hostname for the server in the Subject Alternative Names field: openssl x509 -in <path to cert> -text -noout | grep Alternative -A1 And confirm the certificate's issuer(s) (or the certificate itself in the case of a self-signed cert) are in the SAS trust store for all SASHome paths. (<SASHome>/SASSecurityCertificateFramework/1.1/cacerts/trustedcerts.pem). Issuer of your cert: openssl x509 -in <path to cert> -text -noout | grep Issuer Contents of your SAS trust store (each cert and its issuer): <SASHome>/SASPrivateJavaRuntimeEnvironment/9.4/jre/bin/keytool -printcert -file <SASHome>/SASSecurityCertificateFramework/1.1/cacerts/trustedcerts.pem | grep -E '(Owner:|Issuer:)' ... View more

I'm not clear on what exactly you are trying to do, but the METADATA_SETASSN function is passed an two URIs, that of the object whose association is being modified, and the object being associated. It is additionally passed the name of the association and a modification (append, merge, modify, remove or replace). So, if I had an object "Object A" associated with a single object "Object B" through association "Assocation1", and I wanted to replace this association to "Object B" with one to "Object C" I could use METADATA_SETASSN with the REPLACE or MODIFY mod: metadata_setassn(object-a-uri,"Assocation1","REPLACE",object-c-uri); This replaces the association1 to object b with an assocation1 to object c. If I wanted to retain the object b association I could use APPEND or MERGE to add an association to object c. If I have multiple objects associated with object A through association1 and I want to replace B with C and leave the rest, I would use a REMOVE using the object-b-uri and APPEND or MERGE with object-c-uri, or I could use REPLACE and pass all the existing URIs except object-b-uri, instead adding the object-c-uri. ... View more

The syntax looks right to me, assuming you are using Basic authentication and not a Personal Access Token, in which case you would not set a User it looks like: https://cdn.cdata.com/help/LKJ/jdbc/pg_connectionj.htm ... View more

In that case, I would suspect the issue to be with the authentication option values themselves. Are you able to log in to databricks with the 'client-id' and 'Token' values outside of SAS? ... View more

You are receiving a response from the server so this is not an issue of the incorrect port, I believe the driver assumes https/port 443. The response you are receiving is a 401 unauthorized, so appears to be an issue with your authentication options. If you are wrapping your user and token in single quotes you may wish to try without those. ... View more

This error is saying that the engine is adding a connection property to your url called "useragententry" which the driver is rejecting as invalid. With the cdata databricks driver if you specify the URL directly, you need to use the form: jdbc:databricks:Server= (no :// in the URL) This is probably whats causing the engine to add options for a different driver. ... View more

No, this is a staging location as part of the deploy web applications process, they are not being used outside of that process. As I understand it when you run the "Build Web Applications" task, the WAR/EAR files are generated into Web/Staging, and in the "Deploy Web Applications" the web app servers are stopped, the WAR/EAR files are extracted to Web/Staging/exploded then those extracted files are copied to SASServerX_Y/sas_webapps, and then the web app servers are started again. ... View more