Initializing help system before first use

JavaScript API 2.0 and Later

When upgrading a custom VDL runner or a JavaScript API view from version 1.4 or earlier to version 2.0 or later you need to take the several factors into account.
  • Various API calls have been made asynchronous, returning promise objects.
  • You can no longer get a reference to a scenario synchronously, using the old View#getSelection and View#getFirstScenario methods. You will need to wrap your code in scenario observers.
  • The only way to access scenario data is through scenario observers.
  • To modify scenario data you need to first get a ScenarioDataChange object for that scenario. You also need to call ScenarioDataChange#commit before the data is saved.
  • Most of the calls on ScenarioDataChange to update entities are named the same and accept the same arguments as the previous versions of the API.
  • If you have any calls to ScenarioObserver#notifyLocalChange you should remove them. Local change events are now automatically generated after changes have been applied successfully on the server.

Because a lot of the JavaScript API has become asynchronous this will have the knock-on effect of making your view code asynchronous. Some parts of your code will have to be split into callbacks that can be invoked when these promises resolve. In some cases you can chain the promise objects returned by the API, using the Promise.all() static method for example.

JavaScript API 2.X and later removes the events for scenario job execution from the ScenarioObserver. This was problematic in the past and could lead to design issues in the view. The ScenarioObserver#onStateChange method has been replaced with ScenarioObserver#withSummaryData and the main difference is that now it will not issue updates to your scenario observer during execution. To refactor your views so that they do not need to monitor scenario job execution you may need to augment the Mosel model with some state entities that both the view and the model can update. This way you can detect when a view transitions to the next state after the model has been run. Your view state will then be driven by entity data rather than a sequence of user actions and scenario job execution.

Information about the model solution has been moved from the Scenario object onto the ScenarioSummaryData object. It is easy to get the summary data. 
var summary = scenario.getSummaryData();
summary.getObjective();
summary.getModelStatus();
summary.hasResultData();
If you do need to get the current execution status this is now an asynchronous call and will return a promise: 
scenario.getCurrentExecutionStatus().then(function(status) {
   status.getNumberOfSolutions();
   status.getStatus();
});

The current execution status is passed into the resolve callback of the promise and you can use that object as you did in previous JavaScript API versions. If you need to monitor the execution status then you will need to call this on a regular interval to get the current status.

Parent Topic Upgrading from Xpress Insight 4.0 or Earlier

© 2001-2020 Fair Isaac Corporation. All rights reserved. This documentation is the property of Fair Isaac Corporation (“FICO”). Receipt or possession of this documentation does not convey rights to disclose, reproduce, make derivative works, use, or allow others to use it except solely for internal evaluation purposes to determine whether to purchase a license to the software described in this documentation, or as otherwise set forth in a written software license agreement between you and FICO (or a FICO affiliate). Use of this documentation and the software described in it must conform strictly to the foregoing permitted uses, and no other use is permitted.