Nachvollziehen der Änderungen an einem Arbeitsablauf für das Monitoring

betrieb.eportale

• 13. April 2026 09:01

Hallo liebe Crownpeak Community,

aufgrund einer neuen Anforderung müssen wir künftig Änderungen an einem Arbeitsablauf monitoren. Bei einer Änderung soll eine Benachrichtigung an bestimmte Personen gesendet werden (die Benachrichtigung wird aktuell in Form einer Mail geplant.)

Da uns und dem Crownpeak Support aktuell keine Möglichkeit bekannt ist, wie das Änderungsdatum eines Arbeitsablaufs überwacht werden kann, möchten wir in der Community nachfragen, ob bereits jemand eine entsprechende Implementierung vorgenommen hat.

Nach unserem aktuellen Kenntnisstand wäre die Eigenentwicklung eines Moduls der beste Weg, um die Anforderung umzusetzen.

Über weitere Vorschläge oder alternative Ansätze würden wir uns sehr freuen.

Vielen Dank im Voraus!

0

• 

  Holger Höbbel

  • 13. April 2026 09:59

  Hallo,

  hier würde ich den Lösungsweg abhängig davon machen, wie schnell (und wie oft) eine Benachrichtigung gewünscht ist.

  Wenn sofort bei der Änderung benachrichtigt werden soll, dann würde ich über den IDProviderEventAgent gehen. Diesen in einem Modul verwenden und wenn eine Änderung an den entsprechenden Knoten gefunden wird (im Filter einfach prüfen, ob der geänderte Knoten der entsprechende Arbeitsablauf ist und im Listener prüfen, ob die Änderung relevant ist)

  Wenn beispielsweise nur einmal täglich eine entsprechende Benachrichtigung versendet werden soll, dann kann man auch per Skript in einem Auftrag das Ganze prüfen. Ein Arbeitsablauf ist ja auch ein HistoryProvider, so dass man problemlos prüfen kann, ob es eine Änderung in einer bestimmten Zeitspanne gab. 

  Für den IDProviderEventAgent habe etwas ähnliches mal umgesetzt, um zu prüfen, ob es in bestimmten Datenquellen Änderungen an Datensätzen gab. Wenn ja, soll ein entsprechender Cache zurückgesetzt werden. Hier die entsprechende Implementierung (der Filter lässt nur Events durch, die sich auf Datensätze beziehen. Der Listener prüft dann, ob die Änderung relevant ist). 

          // Register event listener for Content2 changes — granular routing by entityTypeName
          _eventAgent = _projectBroker.requireSpecialist(IDProviderEventAgent.TYPE);
          // Filter: entity-type events only (entityTypeName routing handles Content2 scoping)
          _entityFilter = eventInfo -> eventInfo.getEventType().isEntity();
          _contentChangeListener = event -> {
              Set<ProviderType> allAffected = EnumSet.noneOf(ProviderType.class);
              for (IDProviderChange change : event.getChanges()) {
                  EventInfo eventInfo = change.getEventInfo();
                  for (EntityInfo entity : eventInfo.getEntities()) {
                      String entityTypeName = entity.getEntityTypeName();
                      Set<ProviderType> affected = ProviderType.resolveAffectedProviders(
                              entityTypeName, eventInfo.getEventType());
                      allAffected.addAll(affected);
                  }
              }
              if (!allAffected.isEmpty()) {
                  _dirtyProviders.addAll(allAffected);
                  Logging.logInfo(LoggingPrefix + " Content2 change detected - marked providers as dirty: "
                          + allAffected, LOGGER);
              }
          };
          _eventAgent.addListener(_entityFilter, _contentChangeListener);
          Logging.logInfo(LoggingPrefix + " content change listener registered.", LOGGER);

  Wichtig ist es, daran zu denken, den Listener auch wieder zu entfernen, wenn das Modul gestoppt wird

      public void stop() {
          if (_eventAgent != null && _contentChangeListener != null) {
              _eventAgent.removeListener(_contentChangeListener);
          }

   

  Viele Grüße
  Holger

  0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.