Menu
Introduction
Three features designed to increase the reliability of integration and submission processing:
- The New Queue Processor (NQP)
- Integrations V2
- The New Save Method
Each of these features is available ‘site-wide’ and on a process-by-process or form-by-form basis, apart from the New Save Method, which is only available site-wide and will be available in 2021. Please also note that Integrations v2 can only be enabled for MyServices by enabling the NQP site-wide. Please contact the Support Team to have this done.
We currently will not turn any of these features on site-wide until the New Save Method has been disabled. This is due to interdependencies between the three features which we are working to ‘decouple’, or make independent. The dependencies are:
- The New Save Method is only enabled when the New Queue Processor is turned on site-wide.
- MyRequests V3 only shows saves made with the New Save Method if this is switched on
- Integrations V2 can be turned on by checking the Integrations V2 checkbox on the form or subform. This will cause all lookups in the form or subform and all presubmission integrations attached to the stage to run on V2 integrations. To enable V2 integrations for Creation or Submission integrations attached to the stage, you also need to check the ‘New Queue Processor’ checkbox on the process settings.
These features implement some different behaviour which customers should be aware of if they are switching over from the Old to New Queue Processor or from V1 to V2 integrations.
(Note: New Submission method is enabled site wide at all sites and the tick box in process settings can be ignored)
Go to top
Differences between New Queue Processor and Old Queue Processor
The key improvements are that in the NQP tasks are processed more consistently, and we are able to implement better logging which can help diagnose any processing issues.
- NQP stores tasks against UCRN and email.
- This is part of the implementation of UCRN assignment. Most parts of the platform still show tasks based on the email assignment even when the task also stored the UCRN, however.
- The reason NQP assigns tasks by UCRN rather than email is to avoid a scenario which had arisen in the Old Queue Processor where, if a task had been submitted by a CSA in Service against a user with no email address, the task was assigned to the CSAs email address. This meant that, when using MyRequests, a CSA would see tasks logged on behalf of customers with no email addresses in addition to their own tasks.
- NQP allows submission integrations to write values back to the form.
- Submission integrations under NQP emulate presubmission integrations insofar as they could update form values on submission. However, this update occurs after all calculations and routes have been evaluated, so they do not perform in the same way as presubmission integrations.
Go to top
Differences between V1 Integrations and V2 Integrations
The key improvements are that in V2, the integration runs from the server rather than the browser and that in V2, the validation re-performs all the calculations for tokens used by the integration to make certain that all the values passed are accurate.
Note: Payment integrations are handled differently from other integrations created in the product and whilst they run at a specific time in the integration queue they do not actually use either V1 or V2 at any point. They have their own code base and are executed separately, so the V1 reference in the logs can be ignored.
The following differences are considered known behaviour and will not be changed. For a list of issues with V2 that will be fixed please see below.
Go to top
Expected behaviour in V2
- If you receive the error 'End tag afend:repeat]] does not match tag af:repeat at line 00, character 0' or similar, it is because you have not correctly spaced the CDATA tag in a V2 integration using
@af:if or @af:repeat. Please ensure you retain the spaces around the inner text as this is essential in Integrations V2. {nownotz} token: in V1 it returned the time in GMT, in V2 it correctly returns in UTC.- Subforms are formatted as HTML in V2 integrations so require a # symbol to prefix the token eg.
{#subform1} for them to be formatted correctly in emails/printables. - V2 database integrations sends all values as strings. For example NULL would now be sent as ''.
- When V2 finds an array in the
<body> of a Webservice/HTTP integration response it will introduce a <RepeatableNode> element. This was introduced to make it easier for customers who were previously having to write extensive XSLT to handle array returns. The <RepeatableNode> is expected behaviour for V2 integrations. You can tell if an integration returns an array or not by looking at the Raw Response. An item will return like this: <Body>{"itemName... whereas an array will return <Body>[{"postNumber... - ie. a square bracket indicates your integration is returning an array. Even if your array returns one item it will introduce the repeatable node element. - The
{prev_data} token doesn't work when using NQP and V2. This only affects email integrations; we advise customers wishing to attach a printable to an email to attach it in the integration itself instead of using {prev_data}. -
In v1, sometimes integrations fired twice despite the original integrations running successfully. This problem can be resolved by switching to V2 integrations and the New Queue Processor which already has a fix for this. With V1 the product will send send a request again if it doesn't get a immediate response back. Sometimes this can lead to multiple runs in error. In V2 this has been changed to send a request once with a 60 second time out. It doesn't attempt to resend the request.
- PDFs have different alignment between V1 and V2
- When using V2, content appears to be centre-aligned vertically instead of aligned with the top of the PDF. This is because the table height is now being respected by the PDF generator.
Useful further reading
