Konfiguruj: łącznik EPE Jira Cloud
Dowiedz się, jak skonfigurować łącznik EPE Jira w celu synchronizacji zgłoszeń Jira.
Konfiguruj: łącznik EPE Jira Cloud
Dowiedz się, jak skonfigurować łącznik EPE Jira w celu synchronizacji zgłoszeń Jira.
Jak połączyć Jira Cloud z EPE?
Od wersji 2023.3 Efecte Provisioning Engine (EPE) wprowadza nowy konektor Jira. Zadanie konektora Jira oparte na zdarzeniach jest używane podczas zapisywania danych z platformy Efecte do Jira. Administratorzy EPE mogą konfigurować połączenie z docelową Cloud Jira za pomocą interfejsu użytkownika EPE. Pro mogą być uruchamiane na podstawie zdarzeń, wyzwalane przez Visual Workflow Automation.

Typowe przypadki użycia to:
- Tworzenie zgłoszeń Jira na podstawie incydentów z platformy ESM do Jira
- Importuj zgłoszenia z Jira do platformy ESM
- Przesyłanie komentarzy pomiędzy platformą ESM a Jira
- Rozdzielczość transferu między platformą ESM a Jira
- Tworzenie i usuwanie użytkowników Jira
- Tworzenie i usuwanie grup Jira
- Dodawaj i usuwaj użytkowników z grup Jira
Ogólne uid dotyczące zaplanowanych zadań
General g uid ance for scheduled tasks
How to Create New Scheduled Task to import data
For configuring scheduled-based provisioning task, you will need access to Administration / Connectors tab.
1. Open the Administration area (a cogwheel symbol).
2. Open Connectors view.
3. Choose Connector for Scheduled-based task and select New Task
Note! If connector is not created, you have to choose first New connector and after that New task.

4. Continue with connector specific instructions: Native Connectors
Should I use Incremental, Full or Both?
Scheduled task can be either Incremental or Full -type.
Do not import permissions with AD and LDAP incremental task
Incremental task has issue with permissions importing. At the moment it is recommended not to import group memberships with incremental scheduled task.
On Microsoft Active Directory and OpenLDAP connectors, remove this mapping on incremental task:

Setting on Scheduled tasks:

Incremental type is supported only for Microsoft Active Directory, LDAP and Microsoft Graph API (formerly known as Entra ID) Connectors.
Incremental type means, that Native Connectors (EPE) fetches data from source system, using changed timestamp information, so it fetches only data which is changed or added after previous incremental task run.
When Incremental type task is run for very first time, it does a full fetch (and it marks the current timestamp to EPE database), thereafter, task uses that timestamp to ask the data source for data that changed since that timestamp (and then EPE updates the timestamp to EPE database for next task run). Clearing task cache doesn't affect this timestamp, so Incremental task is always incremental after first run.
Full type is supported for all Connectors.
Full type import fetches always all data (it's configured to fetch) from source system, on every run.
Both Full and Incremental type tasks use also Task cache in EPE, which makes certain imports faster and lighter for M42 system.
By default that task cache is cleared ad midnight UTC time. When cache is cleared, next import after that is run without caching used to reason if data fetched should be pushed to ESM, all fetched data is pushed to ESM. But after that, next task runs until next time cache is cleared, are using EPE cache to determine if fetched data needs to be pushed to ESM or not.
You can configure at what time of day task cache is emptied, by changing global setting in EPE datapump configuration:
/opt/epe/datapump-itsm/config/custom.properties
which is by default set to: clearCacheHours24HourFormat=0
You can also clear cache many times a day, but that needs to be thinked carefully, as it has impact on overall performance as EPE will push changes to ESM, that probably are already there, example(do not add spaces to attribute value): clearCacheHours24HourFormat=6,12
After changing this value, reboot EPE datapump container to take change into use.
Recommendations:
Have always by default Full type scheduled task.
If you want to fetch changes to data fetched already by full task, more frequently than you can run full task, add also incremental task. Usually incremental task is not needed.
Recommended Scheduling Sequence
Recommended scheduling sequence, depends how much data is read from Customers system/directory to the Matrix42 Core, Pro or IGA solution and is import Incremental or Full.
Examples for scheduling,
| Total amount of users | Total amount of groups | Full load sequence | Incremental load sequence |
| < 500 | < 1000 |
Every 30 minutes if partial load is not used Four (4) times a day if partial load is used |
Every 10 minutes |
| < 2000 | < 2000 |
Every 60 minutes, if partial load is not used Four (4) times a day if partial load is used |
Every 15 minutes |
| < 5000 | < 3000 |
Every four (4) hours, if partial load is not used Twice a day if partial load is used |
Every 15 minutes |
| < 10 000 | < 5000 | Maximum imports twice a day, no matter if partial load is or is not used | Every 30 minutes |
| < 50 000 | < 7000 | Maximum import once a day, no matter if partial load is or is not used | Every 60 minutes |
| Over 50 000 | Over 7000 | There might be a need for another EPE-worker, please contact Product Owner | Separately evaluated |
Please note that if there are several tasks running at the same time you may need more EPE-workers. The tasks should be scheduled at different times and can be completed according to the table above. However, if there are more than 6 tasks running at the same time, the number of epeworkers should be increased. It's best practice not to schedule tasks to run at same time, if possible.
Recommendations related to performance
If the amount fo data to be imported is over 10000 concider these things:
Adjust log level of ESM and DATAPUMP to ERROR-level, to lowe the amount of logging during task run
Have as few as possible automations starting immediately for imported datacards (listeners, handlers, workflows), as those make ESM to take longer time handling new datacards.
Set removed accounts and entitlements status removed/disabled
With this functionality, you can mark account and entitlement status to e.g. Deleted or Disabled, when account or entitlement is removed from source system. Starting from version 2025.3 you can also set status to generic objects (not only to accounts/identities and entitlements/groups).
For version 2025.3 and newer
In version 2025.3 these settings are moved from properties files to Task UI. Also you can now set these settings for Generic objects, which have not been possible before this version.
There is separate configuration for each scheduled task, and for all mapping types. Here is example of this config on task:

For version 2025.2 and older
This functionality is available for “full” type scheduled tasks.
Settings are on datapump dockers configuration file. To change those parameter values, you need to set those in /opt/epe/datapump-itsm/config/custom.properties file.
Configuration
To enable disabling functionality, datapump config should have these parameters set to true:
disable.unknown.esm.users=truedisable.unknown.esm.groups=true
Those 2 parameters are false by default in 2024.2 and 2025.1 versions. In 2025.2 and newer version those are true by default.
Next are these parameters:
personTemplateStatusCodeAttributeKey=accountStatuspersonTemplateStatusAttributeDisabledValueKey=DeletedgroupTemplateStatusCodeAttributeKey=statusgroupTemplateStatusAttributeDisabledValueKey=5 - Removed
First two attributes should point to the DatacardHiddenState attribute in the User template, and tell which value should be send there when the user is deleted.
By default its accountStatus and Value 5 - Removed on IGA Account template.
All these needs to match with the attribute configuration:

Same thing applies for the next two paramaters, but its for Groups.'
If you need to change those parameters in properties file, do changes in Datapump container to file: /opt/epe/datapump-itsm/config/custom.properties and those changes will then survive over container reboot and will be copied on reboot to /opt/epe/datapump-itsm/config/application.properties.
Description
Tasks save their __taskid__ shown as Task Id mapping in the UI to the datacards, its then used to determine if the datacard was added by this task. In case there are multiple tasks with different sets of users.
This field was previously used as datasourceid, but since we moved to the model where connector can have multiple tasks its identifier cannot be used anymore, thats why the field was repurposed as taskid instead.
Taking users as an example, when task runs ESM is asked for the list of users that have its taskid in Task Id mapping field, and doesn't have a personTemplateStatusAttributeDisabledValueKey value in the personTemplateStatusCodeAttributeKey
This result is then compared to what the task fetched, and the datacards of users that were not fetched have their personTemplateStatusattribute set to value specified in the config - 5 - Removedby default.
Example log below shows described process and informs that one user was removed.

Same thing applies to groups but groupTemplateStatusattributes are used instead.
Notes
- Feature works only with full fetch scheduled tasks..
- No support for generic templates yet, only identity and access
- When migrating from the previous versions where datasourceid was still used it needs to run at least once to set its taskid’s in the datacards first.
- EPE identifies Disabled users or groups as the ones that were removed from the AD, at the present we do not support statuses related to the entity beign active or not.
- EPE does not enable users back on its own.
- If more than one tasks fetches the same users or groups it may overwrite the taskid in the datacard depending on which task ran last. It is suggested that many full type tasks are not fetching same user or group.
- Always do configuration file changes to custom.properties, do not change only application.properties as those changes are lost on container reboot if you have not done same changes to custom.properties.
Zaplanowano instrukcje krok po kroku
1. Otwórz obszar administracji Efecte (symbol koła zębatego) w prawym górnym rogu. 
2. Otwórz widok łączników

3. Utwórz nowy łącznik Jira (jeśli jeszcze go nie masz)
- Adres URL hosta łącznika Jira powinien mieć format: https://instancename.atlassian.net
- Pamiętaj, aby ustawić wszystkie atrybuty przed kliknięciem przycisku „Testuj połączenie”, co oznacza również użytkownika Web API i jego hasło. Jeśli nie widzisz komunikatu o pomyślnym połączeniu testowym w interfejsie użytkownika (lub widzisz komunikat o błędzie), sprawdź logi główne EPE pod kątem błędów.
- Nazwa użytkownika to użytkownik, który utworzył token dostępu
- Tokeny dostępu są ważne maksymalnie przez rok (ograniczenie po stronie Jira), dlatego pamiętaj o udokumentowaniu daty wygaśnięcia tokena, aby utworzyć nowy token i skonfigurować go w Jira Connection przed jego wygaśnięciem. Więcej informacji znajdziesz na stronie: https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/

4. Wybierz z przeglądu łącznik typu Atlassian Jira , w zadaniach opartych na harmonogramie kliknij „+ Nowe zadanie” 
5. Wybierz kolejność harmonogramowania, która zależy od ilości danych odczytywanych z Jira. Wprowadź unikalną nazwę zadania provisioningowego i zapytania Jira.
- Najlepszą praktyką jest przetestowanie zapytania Jira (JQL) w rzeczywistym systemie Jira, zanim użyjesz go w konfiguracji zadania.
Zobacz także dokumentację Jira:
6. Wypełnij sekcję mapowania atrybutów. Uwaga! Zawartość różni się w zależności od wybranej wartości w polu „Typ mapowania”.

7. Zapisz zadanie provisioningu za pomocą przycisku Zapisz
8. Skonfigurowałeś już zadanie provisioningu oparte na harmonogramie i możesz kliknąć „Uruchom zadanie”, aby w razie potrzeby uruchomić je ręcznie. Możesz też poczekać na automatyczne uruchomienie zgodnie z harmonogramem.

9. Jeśli zadanie jest wykonywane ręcznie (kliknięcie „Uruchom zadanie”) lub jest uruchamiane zgodnie z harmonogramem, status zadania można sprawdzić w sekcji Historia:

Instrukcje krok po kroku oparte na zdarzeniach
1. Otwórz obszar administracji Efecte (symbol koła zębatego) w prawym górnym rogu.

2. Otwórz widok łączników 
3. Wybierz opcję Atlassian Jira Connector z sekcji Przegląd i zadań opartych na zdarzeniach, a następnie przycisk + Nowe zadanie 
4. Wpisz unikalną nazwę zadania provisioningowego
- Typem mapowania musi być Szablon ogólny, gdy obsługujesz (na przykład bilety) inne typy obiektów niż użytkownicy i grupy.

5. Wypełnij sekcję mapowania atrybutów. Uwaga! Zawartość różni się w zależności od wybranej wartości w polu „Typ mapowania”.
- Można ustawić dodatkowe atrybuty, wybierając opcję „Nowy atrybut”, a następnie wpisując nazwę atrybutu i akceptując ją, klikając „Dodaj element”. Jest to bardzo przydatne, jeśli dodałeś własne atrybuty niestandardowe do Jira.

- Można zdefiniować, które informacje o atrybutach będą zapisywane w Jira.
- W Jira może być realizowanych kilka zadań provisioningowych dla różnych celów.
- Aby dodać zgłoszenie w Jira, musisz ustawić co najmniej atrybuty issueType, project i summary, a w zależności od konfiguracji Jira, mogą to być również inne atrybuty. Potwierdź wymagane atrybuty w systemie Jira.

7. Zapisz zadanie provisioningu za pomocą przycisku Zapisz
8. Następnym krokiem jest skonfigurowanie przepływu pracy w celu wykorzystania tego zadania opartego na zdarzeniach. Z poziomu silnika przepływu pracy na platformie Efecte Service Management możliwe jest wykonywanie działań provisioningowych w Jira. Oznacza to, że dowolną z dostępnych aktywności można uruchomić w dowolnym momencie przepływu pracy za pomocą węzła „Orchestration”.
Przykład ustawień węzła Orhcestration dla Jira:

