Skip to Content
avatar image
Former Member

Answering subsequent prompts/contexts


I am doing remapping of data providers to a new data source. Some of the documents require parameters for contexts or prompts to be answered for the data provider to be remapped.

I have used the - GET /raylight/v1/documents/<docId>/parameters call to get the answers for the parameters.  However, I've found that many times that when I POST the remappings with these parameters, a new set of parameters are returned. These set of parameters do not appear in the /raylight/v1/documents/<docId>/parameters call. I am not able to programmatically answer the second set of parameters because I cannot get the answers through the /raylight/v1/documents/<docId>/parameters call.

Is there a way to get the previous answers for these subsequent required parameters?


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    avatar image
    Former Member
    Oct 26, 2015 at 02:22 PM

    I just determined that I can get back a specific parameter by entering an id on the end of the parameters call. I am able to get the subsequent parameter answers this way, but since the id's don't match the id's of the parameters in the mappings call, it's not the greatest help to me. I suppose the only time this would really affect me is when there are multiple contexts - I wouldn't be able to easily ascertain which context is which. Any advice is still appreciated.

    Add comment
    10|10000 characters needed characters exceeded

    • hello Ryan

      "It would seem that calling raylight/v1/documents/<docId>/parameters/ without an id is the same as providing id of 0?" --> No. "/parameters/" without an id get all available (at this time of the workflow) parameters of the document, or the dataprovider, or ...

      "I suppose I can assume that the contexts will be in sequential order based on id though, right?" --> A little bit of yes as we actually increment the parameter id when we discover a new one, but no: we do not guarantee, and I guess we won't ever guarantee, any specific order for the parameters! Please do consider them just as identifiers, which could be any kind of data, We only guarantee that the ids returned by a GET parameters or a previous PUT parameters will be ok to refresh your document, or dataprovider, or LOV, or...

      The documentation should state something like that about contexts: "You must first answer the context before answering the subsequent returned prompt. If no context is provided, the document cannot be refreshed, and the response of the PUT call contains the details about the context parameter."

      It is exactly the same thing with BI LaunchPad when you try to refresh your WebI document: it first shows a popup with the first context, then the 2nd context if any, then the 3rd etc. and then, at least, the prompts.

      To mimic this with "Web Intelligence RESTful web service" in the case of 2 contexts + prompts :

      1. GET parameters --> returns the 1st context.

      2. PUT parameters with the answer to the 1st context as request body --> returns the 2nd context

      3. PUT parameters with the answers to the 1st and 2nd contexts as request body --> returns the prompts.

      4. PUT parameters with the answers to the 1st and 2nd contexts + prompts as request body --> the document should be refreshed.

      Is that a bit clearer?