User dashboard - Follow-up of current requests

Introduction and objectives

The objective of this development is to make a follow-up of the current requests available to the user so that he can know at any time the status of his requests.

A first summary block of the latest requests is visible on the user's dashboard. The latter is only displayed if at least one command is running. It shows the number of queries for each state and displays a detail for the last three queries being updated. Finally, an "All requests" button gives access to the complete list of requests.

Figure 8 : Preview of the current requests summary on the user dashboard.

The listing page allows you to have the details for each request as well as to sort them using three filters. A paging allows not to display all requests on a single page. The mobile version uses an "infinite scroll" instead of paging and has a specific display.

Figure 9 : Preview of the listing page



There are several scenarios depending on the type of service used. Each type of service will interact in a different way with the new elements put in place.

Here are the four types of services discerned:

  • "WebApp" service (by hand) with RequestCenter
  • FBP service with RequestCenter
  • FBP service (without RequestCenter)
  • External service (to Artionet)

The following diagram summarizes the flow of data as a whole:



A new t_gv_RequestsStatus table has been created to store information about current requests. In particular, it contains their status and their BusinessProcessID which makes it possible to identify them. Each line is connected to a user and a service (and possibly to an organization). Finally, the dates of creation and last update are retained.

A new non-mandatory column (BusinessProcessID) has been added to the FormResponse table. This is used to link a form response to its current request and thus be able to update its status when modifying this response.

Types de services

For more details on the update of a service with the follow-up of the requests, please consult the dedicated chapter which refers to it: How to update existing services.

“WebApp” Services with RequestCenter

These services are created by hand and interact directly in the code with the RequestCenter after submission of the form.

These services use a method available to generate a current request and pass its BPID to the RequestCenter through the (already existing) request sent.

FBP Services with RequestCenter

Here, we are talking about the services using FBP form with a sending to the RequestCenter. In this type of case, this sending is generally done via a Provider dedicated to this task.

The Provider used to interact with the RequestCenter is slightly modified in order to create a new current request and to be able to pass its BPID through the (already existing) sent request.

FBP Services without RequestCenter

This type of service uses an FBP form, but this time without any interaction with the RequestCenter.

A dedicated Provider is used in this case. It allows, by using its creation method, to create a new request for follow-up after submission of the form. It also allows to update the follow-up of the request after modification of a response from the Backoffice thanks to its update method.

External Services

External services are those that do not correspond to any of the types presented above.

However, they have the ability to use request follow-up by using a Web Method to create a new current request and retrieve a new BPID.

The external services will update the tracking of their requests with the notifications through the RequestCenter and using the BusinessProcessID related to the request concerned.


The RequestCenterScheduler reads and manages the notifications sent to the eGuichet. In this case, it allows to update the status of a current request by means of the header of a notification.

To do this, the BusinessProcessID element must be populated with the same BPID that it used when creating the request. The BusinessCaseClosed item indicates whether the request should be completed or not.

The new status of the request is defined in NamedMetaDatas. The NameMetaData element with for MetaDataName "BusinessProcessStatus" must contain an integer indicating the new status in its MetaDataValue property.

A Title for the Request can also be defined. The title is inside a NamedMetaData with MetaDataName equal to “RequestTitle”. This title can contain multiple translations terms and use the slot {{BusinessProcessID}} in those terms to display the BPID.

Here is an example of what RequestTitle could be:
 {{Term:My.Term.01}} JU-25862 {{Term:My.Term.02}}

Translated to : 
 Votre demande de permis de remplacement pour le véhicule immatriculé JU-25862 avec le numéro 7120b5ec-0ef6-4b6a-9ff5-73ddeb401c02 a été délivrée

In this example, we use the slot {{BusinessProcessID}} in {{Term:My.Term.02}}. The end of the sentence indicating the status is provided by the following terms and are automatically added at the end :

  • GV.Portal.Dashboard.Default.RequestsStatus.Title.EndStatus.Submitted
  • GV.Portal.Dashboard.Default.RequestsStatus.Title.EndStatus.Running
  • GV.Portal.Dashboard.Default.RequestsStatus.Title.EndStatus.Delivered
  • GV.Portal.Dashboard.Default.RequestsStatus.Title.EndStatus.Rejected

Finally, a default title is used if no title is provided.

For more details on the elements of the header, please refer to the specification document.

Figure 10 : Location of the status in the notification header


Summary of current requests

The current requests summary is on the user dashboard.

  • The entire summary area is hidden if no requests are in progress.
  • Each of the Status "Counters" is displayed only if its count is nonzero.
  • The "Counter" can be clicked and leads directly to the list of requests with the active "Status" filter linked to the clicked counter.
  • The last three requests sorted by update order are displayed below the counters
  • The Title of the requests is used to display the last requests. If there’s no title defined for a request, a default title will be used.

Full listing of current requests

The complete current request list is accessible via the "All requests" button located at the bottom of the current request summary on the User Dashboard.

By default, all requests are displayed in the order of the most recent update to the oldest. It is however possible to filter the requests thanks to the three filters: Status, Theme and Service. The content of the filters is updated according to the filtering choices already made. Finally, it is possible to reset all filters in one action with the "Reset All Filters" button.

This list has two different views; Desktop and Mobile.


  • The list is displayed in a tabular format
  • "Manual" pagination with 16 elements per page is used.
  • The filters are located above the list.


  • The list is displayed as a list and no longer a table.
  • A total of 10 items are displayed. An "Infinite scroll" is used to display the next elements when the user scrolls to the bottom of page.
  • Each element is summarized, but clickable to display all information.
  • Other elements of the page such as filters and information are accessible from the "..." menu at the top right.
  • After filter selection, refresh is performed when the menu is closed.

Figure 11 : Preview of the mobile display of the listing

How to update existing services

This chapter explains how to update a service so that it can work with the follow-up system.

For explanations of what the following types of services are or are not, please refer to the Types de services chapter.

“WebApp” Services with RequestCenter

The Create method of the Acju.Auth.DataAccess.Entities.RequestStatus class is used to create a new request in progress and retrieve its BusinessProcessID. It requires the user and service (optional organization) identifiers concerned by the request.

Since this kind of service is already in contact with the RequestCenter, a call probably already exists to create the RequestCenter request. It only remains to provide the BPID returned, which will place it in the header of the request made to the RequestCenter.

FBP Services with RequestCenter

As for the “WebApp” Services with RequestCenter, just call the Create method of the class Acju.Auth.DataAccess.Entities.RequestStatus to retrieve a BPID and pass it to the request issued to the RequestCenter.

With the difference that it will be necessary to make this modification in the Provider used by the service to interact with the RequestCenter.

FBP Services without RequestCenter

To adapt these services, it will be necessary to use the RequestsStatus Provider. It has a Create method as well as an Update method.

Several configurations are needed to make the form work with the follow-up of the requests.

Adding a new Messaging Provider

First, if you have not already done so, add the provider in the Backoffice of the virtual counter:

  1. Go to the "Objects" menu from the Backoffice dashboard.
  2. Then go to the "Messaging Providers" section.
  3. Verify that the RequestStatus Provider is not already in the list.
  4. If it is not present, click on the "Add" button and fill in the fields as in the screenshot below:

  5. Then click on « Save »

Preparing the hidden fields of the form

Once the Messaging Provider is in place, you can access the edition of your form and open the tab "Content".

We must now add three hidden fields that will store different information to transfer to the provider that we will link to the form later.

To do this:

  1. Add a first hidden field with the name "UserID" and choose "GV - UserId" from the Binding list.
  2. Add a second hidden field with the name "OrgID" and choose "GV - OrganizationId" from the Binding list.
  3. Add a third hidden field with the name "PrestaID" and choose "GV -PrestationId" from the Binding list.

Important: If you do not see the options shown in the Binding list, the corresponding Bindings are not enabled in the Layout.config file within the FBP section.

Configuring the Messaging Provider in the form

With the three hidden fields in place and configured, you can access the "Bindings" tab to link the Provider:

  1. Click the "Add New Configuration" button
  2.  Copy the configuration below. If you do not find the right provider in the list, or if these Actions are not listed, there is a problem with the Messaging Provider configurated previously:

  3. Go to the "Bindings(Create)" tab
  4. Edit "FormResponseUniqueID", choose "Template" as Language and put the following text for Expression, then save: {{ResponseUniqueID}}
  5. Edit "OrganizationID", choose "ApplicationParameter" as Language and choose "Field: OrgID" in Application Parameter. Save the changes
  6. Edit "PrestationID", choose "ApplicationParameter" as Language and choose "Field: PrestaID" in Application Parameter. Save the changes
  7. Edit "UserID", choose "ApplicationParameter" as Language and choose "Field: UserID" in Application Parameter. Save the changes
  8. Click on "Save"
  9. To complete the configuration of the provider, check the boxes as below:

Configuring the Work Stream in the form

Caution: For Work Streams to work properly, the IIS user must have read and write permissions to the C:/Windows/Temp/ folder.

You can now access the "Work Stream" tab.

  1. Click on "Add a new stream"
  2. Enter "Status Change" as the name and leave all other options as default before saving.
  3. In the Work stream drop-down list at the top, choose your new work stream ("Change Status").
  4. Click the "Add a new configuration" button
  5.  Configure the options as in the screenshot below:

  6. Go to the "Bindings(Update)" tab
  7. Edit "FormResponseUniqueID", choose "Template" as Language and put the following text for Expression, then save: {{ResponseUniqueID}}
  8. Click on "Save"
  9. Finally, configure the checkboxes as below:

Configuring the Custom statuses

Each form response has an internal (basic) status. Here we will use the custom statuses. In order to use them you must first activate them if you have not already done so:

  1. Go to the "Configurator" tile from the Backoffice Dashboard.
  2. Click on the "Global Parameters" menu
  3. Locate "FormBuilderProEnableCustomStatuses" and set it to "1" if it already exists.
  4. If it does not exist, create a new parameter with the "Add" button and give it the name "FormBuilderProEnableCustomStatuses". Put "1" as a value.

The four new statuses (submitted, in process, issued, rejected) must now be manually added to the FormResponseCustomStatus table.

Once the statuses are in the table, you can add the following four global parameters from the Backoffice and assign them the corresponding ID value in the database (in the FormResponseCustomStatus table). You can add directly the status name in your language and then use this translation term to translate it: FormBuilder.Translation.CustomStatus{id}.Name. Replace {id} with the id of the status in the database. Those translations are only used in the Backoffice.

  • FormResponseCustomRequestStatusIDSubmitted
  • FormResponseCustomRequestStatusIDRunning
  • FormResponseCustomRequestStatusIDDelivered
  • FormResponseCustomRequestStatusIDRejected

Figure 12 : In the Parameters tab of your form you can set the default used status

 The last step is to go to your form and configure the custom statuses from the "Settings" tab as in the screenshot below. Here we have chosen to use the "Submitted" status when the form is submitted:

External Services

Current Request Creation and GUID Retrieval

External services can use request tracking by using the CreateRequestStatus method available in the Acju.GV.Portal.Services.AjaxRequests class.

AjaxRequests is a SOAP Web Service. To use it, just use the provided WSDL file (AjaxRequests.wsdl) as a Web Reference. Below is an example of code with use of the method cited:

using System;
using TestCreateRequestsStatus.AjaxRequests;

namespace TestCreateRequestsStatus
    class Program
        static void Main(string[] args)
            var proxy = new AjaxRequestsSoapClient();
            Console.WriteLine("-- Start --");
            Guid? myGuid = proxy.CreateRequestStatus(76, null, 1005, "123456");

            if(myGuid != null)
                Console.WriteLine($"Here is your guid : {myGuid.Value}");

Figure 13 : Console application illustrating the use of the Web Service.

La méthode CreateRequestStatus permet de créer une nouvelle entrée dans les demandes de suivi en fournissant les identifiants de l’utilisateur et de la prestation (organisation optionnelle) et ainsi récupérer un BusinessProcessID nouvellement créé.

Le mot de passe de la méthode doit être fourni en dernier paramètre afin de valider la personne utilisant la méthode. Ce mot de passe est comparé avec celui indiqué dans le fichier web.config sous le paramètre « RequestsStatusCreationMethodPassword ».

The CreateRequestStatus method allows you to create a new entry in the current requests by providing user and service identifiers (optional organization). Thus, retrieve a newly created BusinessProcessID.

The password of the method must be provided as the last parameter to validate the person using the method. This password is compared with the one specified in the web.config file under the "RequestsStatusCreationMethodPassword" parameter.

      <setting name="RequestsStatusCreationMethodPassword" serializeAs="String">

Figure 14 : Parameter of the web.config file to fill in the password.

Updating an existing request

The external services will update the follow-up of their requests through with notifications through the RequestCenter and using the BusinessProcessID related to the request concerned.

For more information about the data to be provided to the notification header for a status update, please read the RequestCenterScheduler chapter.


Below, the terms of translations added for the purposes of this feature:




































IceCube2 Settings

Apart from the parameters for linking the custom statuses, there is another parameter to manage the display of the request tracking.

  • DashboardClosedRequestsMaximumDaysDelay: This parameter determines the number of days during which a closed request will still be displayed to the user after its last update.