RESTAPI - Only Supports Default Workspace Currently?
Just a heads-up for anyone using the REST API - this may save you some head-scratching! GetAdoDataSetForAdapter (5.2.0/Synchronous) and non-Default Workspaces There appears to be a problem with running GetAdoDataSetForAdapter if your DataAdapter is not in the Default Workspace. The Data Adapter returns an HTTP/200 in PostMan BUT the Response Body is null. It appears that the WorkspaceName parameter in the RequestBody has not yet been implemented in the RESTAPI. The RESTAPI documentation still referes to this parameter as being "reserved for future use" (but I assumed that this was a documetation bug as non-Default Workspaces have been out for a while in 7.4/8) API Version 7.2.0 and Workspaces In the Asynchronous APIs (7.2.0), there seems to be no way to specify the Workspace when you are generating the Application Session Token (SI), so you get the same problem with Data Adapters not in the Default Workspace. I proved this by moving my Data Adapters to the Default Workspace at which point they worked perfectly via the REST API whether via API-Version 5.2.0 or 7.2.0) UPDATE: Workspace has to be set to Shareable for this to work - all Ok now! (Wasn't in the REST API Guide) Steve
REST API reliability challenges in Azure
For those of us that are software developers, we are accustomed to this message. "The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. This issue occurred after 68 seconds." When this issue comes up, it is normally because of some event that breaks TCP connectivity. Occasionally this happens because of network misconfiguration, or load-balancer misconfiguration. This is one of two errors we are seeing after migrating our REST api workloads to onestream's Azure environment. It happens fairly frequently, albeit in an unpredictable way. I haven't found a pattern yet. It doesn't happen on-premise. If anyone has experience deploying a REST api solution to Azure, please let me know if this is an error message you encounter frequently. It may not even be a problem with onestream's software; perhaps the root cause is with the Azure load-balancer. I am also looking into other possible explanations, like SSL inspection. Any tips would be greatly appreciated!
