Skip to main content

Hello, 

I am trying to get a better understanding of the workings of the REST API Endpoint we can add to a semantic model. Specifically what certain actions do withing the whole framework. I'll sketch my case below:

We have configured and deployed a working API Endpoint that contains a table Currency_Rates (From_code, To_code, Date). The endpoint is called api-endpoint and the the webserver is called webserver-endpoint. We have everything working properly: so we can successfully make the following request:

R1 =  <URL>/api-endpoint/data/Currency_Rates?$Top=2&$OrderBy=Date desc.

 

Now I change the name of the date column: Date → Curr_date. This means, I would now like to start using 

R2 = <URL>/api-endpoint/data/Currency_Rates?$Top=2&$OrderBy=Curr_date desc.

Furthermore I would expect R1 to return with an error. 

Now please consider the following actions:

  1. Deploying the instance/endpoint (← nothing to deploy according to TX)
  2. Saving the instance (as the deployed version)
  3. Clicking the “request to refresh config” in the portal (see image below)
  4. Recycle application 
    Request webserver to refresh configuration

     

My questions:

  1. If I click on deploy, then I get a message that there is nothing to deploy. I would not expect this, considering I just made a change to the model. Why is this? And what does deploying do for a REST API endpoint?
  2. The only way I can get my changes to take effect (ie. R1 error; R2 json response) is do perform actions 2 and 4. Is this the way? Personally I would rather not have to recycle the application after every change. 
  3. What does/should action 3 do? I didn't see any changes after the refresh request. 
  4. What are the minimal actions according to TX that should be taken for changes to the semantic model to be visible through the endpoint? Or in other words: is may way of working correct?

Sorry for the overload of questions. Just trying to get a grip on this new endpoint.

 

Kind regards,
​​​​​​​Benny Aalders

Hi @Benny 

Deploying relates to changes to the databases either a DW Data Area or SSL Model, not the database that hosts the settings. With this there probably is no location outside this to store it in.

I will see if I can get some info about the behavior you experience. In the mean time you should use the save as deploy or force a deploy when it can’t find any changes.

https://use.vg/bs3vV3

Doing this is somewhat similar to saving as deployed as all it does when forcing the deploy is to save the instance.

Hi @Benny 

I got an official answer as well, so it seems my suggestion was correct.

  1. The REST API endpoint doesn't really have anything to deploy (for now). However, we use the latest deployed version of the SSL when reading the config, that's why we need the deploy. 
  2. You do not need to do action 4, action 3 should be enough (after deploying/saving)
  3. Action 3 triggers a config update on the REST API webserver. It will then request the latest configuration (tables, columns etc). Note that it may take a few seconds before this takes effect. 
  4. These steps is needed:
    1. The endpoint needs to be deployed/saved, either by:
      1. Deploying with differential deployment and clicking "Yes" on the nothing to deploy question. The deploy window that opens can be closed. 
      2. Disable differential deployment and doing the deploy
    2. The REST API webserver config needs to be updated, using the “request to refresh config”. 

We recognize that this process is a little bit clunky. Will look into improving it. 

Reply


Terms and ConditionsCookie settings