Model Instances

When you make an API call that requires a resource ID, you simply substitute the string you get from the Location header for id. Afterwards, you can call additional RASON REST API endpoints to place the model or decision flow in the queue on the Server such as GET rason.net/api/model/{id}/solvetype where solvetype can be solve, optimize, simulate, datamine,decision or diagnose. (Use solvetype=solve to solve a decision flow or any type of problem type: optimization, simulation, data science or decision.) After the model/flow is placed in the queue, you should periodically check the status of the model, using GET rason.net/api/model/{id}/status, which will either be "complete" or "incomplete". Once the model/flow has finished solving, or the status returned is "complete", then you can call GET rason.net/api/model/id/result to obtain the final solution to the model or flow. The model/flow is merged with the instance and the RASON log will have only a timestamp to distinguish different runs or model instances – the IDs will be the same.

In RASON V2020 and later, when a model/flow is solved via the new REST API endpoint POST rason.net/api/model/id/solvetype (solvetype can once more be solve, optimize, simulate, datamine, decision or diagnose), where {id} is again the ID of the (desired version of) model or flow. The call will return a Location header with a new resource ID that identifies this unique instance (model/flow bound to data). The client should use this new ID in subsequent calls to GET rason.net/api/model/id/status, GET rason.net/api/model/id/result etc. and the RASON log will uniquely identify this model/flow instance via the new resource ID.

The timestamp embedded in this ID records the date and time when the model was run, and when any regularly-updated data sources (OneDrive, CDS, CData CloudHub) were accessed by the model instance.