New features

Web Service Call gains raw mode

Raw mode gives you direct access to the raw data that is sent and received by the Web Service Call component. Instead of modeling an entity and mapping data tables to it you work directly with text or binary data. It also supports multi-part content, for those unusual web services that require it.

You can use raw mode when you need to call a web service that for example:

• Uses XML or JSON that is impossible or inconvenient to model as an entity.
• Uses text content that is neither XML nor JSON.
• Expects multipart content.

Raw mode is configured on a method request/response basis. You can have a web service that uses entities for some of its methods and raw mode for others, and even a method that uses a raw request but receives an entity as response.

Web Service Call can give new commands in the store response calls

Originally the Web Service Call component required you to list all requests that should be performed at once, in the Get requests call. Now, like with the Microsoft Graph and File Manager components you can output additional requests when receiving responses, in the Store response and Store raw response calls.

For example, you could use one request to retrieve the names of all mailing lists, then based on the response output one request to get the recipients for each mailing list, and finally one request to update the recipiends for each mailing list that needs updating.

Web Service Call can receive HTTP status codes

You can now choose to receive the HTTP status code (200 OK, 404 not found, etc.) as part of the Store response call. In raw mode you will always receive the HTTP Status Code.

This allows you to interact with web services that communicate using status codes, and also to implement some basic error handling.

Internal changes and development features

Link alias support in Multipart

You can now use link aliases as an alternative to link ids in Multipart stored procedures. The multipart guide will now generate procedures that use aliases instead of ids.

ADMIN_UnselectAll now seeks further back for checkboxes to clear

ADMIN_UnselectAll will now seek backwards until it finds a Grid or Calendar menu item that can show checkboxes instead of always affecting the previous menu item.

Let's say you have a grid Issues with checkboxes and a top link to an Execute menu item Archive selected issues. The Archive selected issues menu item can then use ADMIN_UnselectAll to unselect all of the grid's checkboxes after it has done its job. So far, so good. Now you want the Archive selected issues menu item to instead be a grid that shows a preview of what's about to happen and then another top link Do it! actually performs the operation. Previously the Do it! menu item could not clear the checkboxes of the Issues grid, but now it can.

Step back to specific menu item

Sometimes you have a menu item flow where you want to step back to a specific menu item, but the exact amount of steps back varies.

For example, you could have a grid Course occasions with the row links Show occasion and Delete occasion, and then the Show occasion menu item also has a link to Delete occasion. In that case you usually want the delete menu item to step back to the grid regardless of how you reached it, as stepping back to Show occasion for a deleted occasion will not be useful.

Before you had to solve this by using ADMIN_CidStepsBack and trying to keep track of how many steps back you should go, depending on which link was used. This worked fine but was inconvenient.

The new feature, Go back to menu item when declaring forwarding metadata on a menu item, or ADMIN_ReturnToMenuItem when specifying forwarding dynamically from the procedure, allows you to specify exactly which menu item should be stepped back to without having to know how many steps back it is. The feature can also in some circumstances be used as an alternative to the CID nexus advanced feature.

Do note that the feature requires the menu item it steps back to actually be in the user's menu item history.