Wiki source code of Rafraîchissement sur événement externe
Last modified by Aurelie Bertrand on 2026/07/23 10:08
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{ddtoc/}} | ||
| 2 | |||
| 3 | ---- | ||
| 4 | |||
| 5 | Refresh on external event allows you to specify that the element should be refreshed upon receipt of an external event via a “fire event” URL. | ||
| 6 | |||
| 7 | The “fire event” URL works with the scheduler. The scheduler must therefore be configured and enabled: see the page [[Schedules>>doc:Digdash.deployment.configuration.configuration_guide.scheduler.WebHome]] for further details. | ||
| 8 | This mechanism allows you to trigger a refresh as if it were scheduled on a calendar, but immediately upon entering the URL. | ||
| 9 | |||
| 10 | = Configuring event-based refresh = | ||
| 11 | |||
| 12 | To configure event-based refresh, you must add a schedule to both the {{glossaryReference glossaryId="Glossary" entryId="Flux"}}Flow{{/glossaryReference}} **__and__ **the** **cube: | ||
| 13 | |||
| 14 | 1. In the External Event ID field, enter the name of the event. For example, EVENT1. | ||
| 15 | 1. You can set a minimum interval between two refreshes: | ||
| 16 | 1*. ((( | ||
| 17 | Tick the **‘Limit maximum refresh frequency’ **box and** **set the frequency as described [[here>>doc:Digdash.user_guide.studio.Schedule_refresh.Automatic_refresh.WebHome||anchor="Planification" style="background-color: rgb(255, 255, 255);"]]. | ||
| 18 | ))) | ||
| 19 | |||
| 20 | For example, the configuration below specifies that the {{glossaryReference glossaryId="Glossary" entryId="Flux"}}Flow{{/glossaryReference}} and the cube will be refreshed upon receipt of the //EVENT1// event no more than once every 5 minutes. If no event is received, the {{glossaryReference glossaryId="Glossary" entryId="Flux"}}Flow{{/glossaryReference}} and the cube are not refreshed (or are refreshed according to a different schedule). | ||
| 21 | |||
| 22 | [[image:Schedule_event_en.png]] | ||
| 23 | |||
| 24 | You can define multiple events on a flow/cube, and a single event can apply to multiple flows/cubes. This can be used to configure different refresh ‘channels’, for example. | ||
| 25 | |||
| 26 | = Triggering the event = | ||
| 27 | |||
| 28 | The event is triggered via a URL entered manually into the browser or sent by an external process, such as the Windows Scheduler. This URL takes the following form: | ||
| 29 | __http:~/~/localhost:8080/ddenterpriseapi/fireevent?eventid=EVENT1__ | ||
| 30 | |||
| 31 | (% class="box warningmessage" %) | ||
| 32 | ((( | ||
| 33 | ❗The event name is case-sensitive. | ||
| 34 | ))) | ||
| 35 | |||
| 36 | * When triggered manually, a login screen appears and the event is launched immediately after authentication. | ||
| 37 | There is no response other than a message indicating that the event has been sent. This response does not guarantee that the event will be processed, nor when. This is because, if the scheduler is already processing a task, the flows affected by the event are queued. Furthermore, if the previous identical event received is too recent (depending on the defined maximum refresh rate), then the new event is ignored. | ||
| 38 | * In the case of an external process, you must add the following to the end of the URL: **&user=**<username>**&pass=**<password> so that the URL call is authenticated. | ||
| 39 | The account in question must have the//‘Schedule refreshes’// authorisation. | ||
| 40 | It is also possible to specify particular users for whom the flows and cubes targeted by the event will be refreshed. To do this, add the parameter **&users=<USER ID>** as many times as there are users to specify. For example: | ||
| 41 | __** http:~/~/localhost:8080/ddenterpriseapi/fireevent?eventid=EVENT&user=...&pass=...&users=user1&users=user2**...__ etc. | ||
| 42 | |||
| 43 | (% class="box infomessage" %) | ||
| 44 | ((( | ||
| 45 | It is also possible to trigger the event via a button added to the dashboard. See the section [[Add additional elements>>doc:Digdash.user_guide.dashboard.dashboard_editor_guide.create_dashboard.additional_content.WebHome||anchor="Contenu_additionnel"]] to find out more about adding a button. | ||
| 46 | Select the **‘Send a refresh event’** action and select the event. | ||
| 47 | |||
| 48 | [[image:action_event_en.png]] | ||
| 49 | ))) | ||
| 50 | |||
| 51 | (% class="wikigeneratedid" %) | ||
| 52 | **Using fireevent with the Talend ETL tool** | ||
| 53 | |||
| 54 | (% class="wikigeneratedid" %) | ||
| 55 | To use fireevent with the Talend ETL tool, you need to use a curl request in the Talend script in the following format: | ||
| 56 | |||
| 57 | (% class="wikigeneratedid" %) | ||
| 58 | //curl -L -b /path/to/talendwrite/cookies.txt -i "http:~/~/urlserver:8080/ddenterpriseapi/fireevent?eventid=EVENT&user=admin&pass=admin// | ||
| 59 | |||
| 60 | (% class="wikigeneratedid" %) | ||
| 61 | Please note: | ||
| 62 | |||
| 63 | * The key parameter is "-L", which allows you to track the "redirect location" in the headers. | ||
| 64 | * The cookie file is not an input parameter. | ||
| 65 | * Do not use the Talend thttprequest component. | ||
| 66 | * You must use CURL with "\"" around the URL in the "tSystem" component. | ||
| 67 | |||
| 68 | == Specifying user parameters in the URL{{id name="URL"/}} == | ||
| 69 | |||
| 70 | It is possible to specify one or more user parameters in the FireEvent URL so that the cube is generated and the associated flows are synchronised for all users with these user parameters. To do this, add the **&searchParam** attribute to the end of the URL as many times as there are user parameters to search for. The URL will therefore take the following form (here, with two user parameters specified): | ||
| 71 | |||
| 72 | __URLServer/fireevent?**loginForm=true&eventid=EVENT_ID&user=USER_USED_TO_REFRESH&pass=USER_PASSWD&searchParam=PARAMETER1%3DVALUE1&searchParam=PARAMETER2%3DVALUE2**__ | ||
| 73 | |||
| 74 | (% class="box infomessage" %) | ||
| 75 | ((( | ||
| 76 | ℹ "%3D" corresponds to the encoding of the "=" sign. | ||
| 77 | %7 corresponds to the encoding of the "|" sign. | ||
| 78 | ))) | ||
| 79 | |||
| 80 | (% class="wikigeneratedid" id="HExemples" %) | ||
| 81 | **Examples** | ||
| 82 | |||
| 83 | * To** run **the event only for users with the value "//FR//" for the "//country//" user parameter, we use the following URL: | ||
| 84 | __http:~/~/localhost:8080/ddenterpriseapi/fireevent?loginForm=true&eventid=EVENT_ID&user=USER_USED_TO_REFRESH&pass=USER_PASSWD&searchParam=country%3DFR__ | ||
| 85 | * To run the event only for users whose ‘country’ parameter is set to//‘FR’//,//‘ES’// or//‘BE’//**, we **use the following URL__:__ | ||
| 86 | __http:~/~/localhost:8080/ddenterpriseapi/fireevent?loginForm=true&eventid=EVENT_ID&user=USER_USED_TO_REFRESH&pass=USER_PASSWD&searchParam=country%3DFR%7CES%7CBE__ | ||
| 87 | * To trigger the event only for users who do not have a value set for the//“country”// user parameter, we use the following URL__:__ | ||
| 88 | __http:~/~/localhost:8080/ddenterpriseapi/fireevent?loginForm=true&eventid=EVENT_ID&user=USER_USED_TO_REFRESH&pass=USER_PASSWD&searchParam=country%3D__ | ||
| 89 | * To trigger the event only for users who have any value set for the//‘country’// user parameter, we use the following URL: | ||
| 90 | __http:~/~/localhost:8080/ddenterpriseapi/fireevent?loginForm=true&eventid=EVENT_ID&user=USER_USED_TO_REFRESH&pass=USER_PASSWD&searchParam=country__ | ||
| 91 | |||
| 92 | = Existing events{{id name="Event"/}} = | ||
| 93 | |||
| 94 | Events already exist in DigDash and can be triggered at any time: | ||
| 95 | |||
| 96 | * **EVENT_STOPSESSIONS**: disables the session manager (users, apart from the super administrator, cannot log in). | ||
| 97 | * **EVENT_STARTSESSIONS**: enables the session manager. | ||
| 98 | * **FORCE_FILESGC**: deactivates all sessions and clears obsolete files to minimise disk space usage. | ||
| 99 | * **EVENT_REFRESHFLOW_FORCE**: refreshes all system flows (except disabled ones) and forces the regeneration of top-level cubes. (//Equivalent to ‘Synchronise for All Users’ + ‘Force generation of cubes from data in the selected Flows’ in Studio//). | ||
| 100 | * **EVENT_REFRESHFLOW_FORCEALL**: refreshes all flows in the system (except disabled flows) and forces the regeneration of all cubes. (//Equivalent to ‘Synchronise for All Users’ + ‘Force generation of cubes from selected data flows’ AND ‘Force generation of all dependent cubes’ in Studio//). | ||
| 101 | |||
| 102 | It is possible to define a sequence of events. For example: | ||
| 103 | |||
| 104 | //.../fireevent?eventid=EVENT_STOPSESSIONS&eventid=REFRESH&eventid=EVENT_STARTSESSIONS// | ||
| 105 | disables the session manager, then refreshes all flows (if the REFRESH event is recognised by the portfolio), then re-enables the session manager. | ||
| 106 | |||
| 107 | .../fireevent?eventid=REFRESH&eventid=FORCE_FILESGC | ||
| 108 | refreshes all flows (if the REFRESH event is recognised by the portfolio) and then clears obsolete files to minimise disk space usage. |