amelnik
I'm new here

Bug in UX-Bridge Generierung und Cleanup

Hallo zusammen,

Ich beschäftige mich derzeit mit dem Modul UX-Bridge (v. 1.8) und versuche eine Vollgenerierung mit anschließendem Aufräumen von alten Inhalten hinzubekommen.

Dabei habe ich mich an die entsprechenden Doku gehalten stehe aber nun vor einem Problem, wo ich nicht weiß ob es ein Bug ist, oder ich etwas ausgelassen habe.

Ich bin für jede Hilfe dankbar!

Die Generierung besteht aus 7 Schritten:

1. UX-Bridge aktivieren (script)

#! executable-class

com.espirit.moddev.uxbridge.inline.UxbInlineUtil

2. Generierung (generate)

Hier werden die UX-Bridge Messages generiert, die verschickt werden

3. UX-Bridge deaktivieren (script)

#! executable-class

com.espirit.moddev.uxbridge.inline.UxbDeactivate

4. Modify start time (script)

//!Beanshell

import java.util.Date;

import java.util.Calendar;

//not the start time of the job, but the oldest revision

context.logInfo("OLD START TIME: " + context.getStartTime().getTime());

Calendar cal = Calendar.getInstance();

cal.setTime(context.getStartTime());

cal.add(Calendar.MINUTE, -60);

Date modifiedStartTime = cal.getTime();

context.logInfo( "MODIFIED CALENDAR TIME" +modifiedStartTime.getTime());

context.setStartTime(modifiedStartTime);

//not the modified calendar time, but the computed revision for the modified calendar time

context.logInfo("NEW START TIME: " + context.getStartTime().getTime());

5. UX-Bridge aktivieren cleanup (script)

#! executable-class

com.espirit.moddev.uxbridge.inline.UxbInlineUtil

6. Generierung cleanup (generate)

Hier werden die UX-Bridge Messages generiert, die alte (also nicht im Schritt 2. generierten) Dokumente löschen sollen.

7. UX-Bridge deaktivieren cleanup (script)

#! executable-class

com.espirit.moddev.uxbridge.inline.UxbDeactivate

Die Logausgaben aus Schritt 4. scheinen auch die richtige Berechnung zu liefern:

INFO  14.03.2016 15:30:58.226 (de.espirit.firstspirit.impl.access.ScriptContextImpl): OLD START TIME: 1457965789490

INFO  14.03.2016 15:30:58.227 (de.espirit.firstspirit.impl.access.ScriptContextImpl): MODIFIED CALENDAR TIME: 1457962189490

INFO  14.03.2016 15:30:58.228 (de.espirit.firstspirit.impl.access.ScriptContextImpl): NEW START TIME: 1457961624247

Die Nachrichten, die aber nach dem Versand über die UX-Bridge aus Schritt 6. am Adapter ankommen, haben leider die gleiche

"startTime" wie die aus Schritt 2. , also werden alle (auch die frisch generierten) Nachrichten gelöscht.

Bereits verifiziert:

- Für sich alleine funktionieren die Schritte 1.-3. und alle Inhalte werden erzeugt.

- Die Löschung an sich funktioniert ja auch, weil die generierten Dokumente auch wieder gelöscht werden.

- Als Alternative habe ich bereits die API Variante aus der Doku (uxbService.removeUxbEntriesByTime) auch ausprobiert, allerdings mit einem anderen Fehlverhalten, was ich bei Bedarf näher erleutern kann.

Vielen Dank im Voraus!

Beste Grüße,

Alex

0 Kudos
5 Replies
thmarx
I'm new here

Hallo Alex,

das deaktivieren der UX-Bridge ist nur notwendig, wenn du danach noch eine "normale" Generierung machen möchtest. Da das cleanup auch eine UX-Brdige Generierung ist, solltes du das deaktivieren weglassen.

In meinem Auftrag sieht das foglendermaßen aus:

  1. UX-Bridge – Activate Generation
  2. UX-Bridge Generate
  3. UX-Bridge Statistics Report
  4. UX-Bridge - Cleanup

Mein Cleanup-Skript sieht so aus:

import com.espirit.moddev.uxbridge.api.v1.service.UxbService;

uxbService = context.getConnection().getService(UxbService.class);

uxbService.removeUxbEntriesByTime(context.getStartTime().getTime(), "news", "postgres,mongodb");

Damit kommen in den Nachrichten auch die korrekten startTimes.

Was machst du in dem Schritt: "6. Generierung cleanup (generate)"

Viele Grüße

Thorsten

0 Kudos

Hallo Thorsten,

mein Schritt 6. generiert im UXB Kanal Meldungen wie:

<uxb_entity uuid="4711"

                              destinations="elasticSearch"

                              language="DE"

                              command="cleanup"

                              objectType="myObjectType"

                              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                              path="$CMS_VALUE(if(#global.preview,"",#global.scheduleContext.path))$"

                              schedulerId="$CMS_VALUE(if(#global.preview,"0",#global.scheduleContext.task.scheduleEntry.id))$"

                              projectId="$CMS_VALUE(#global.project.id)$"

                              createTime="$CMS_VALUE(#global.now.milliseconds)$">

</uxb_entity>

Für sich alleine funktionieren die Schritte 5-7 ja auch. Mein Problem ist, dass ich die startTime nicht manipulieren kann um dokumente nur bis zu einem bestimmten Zeitraum in der Vergangenheit zu bereinigen.

Deine Lösung habe ich auch bereits ausprobiert, und habe davor versucht die startTime zu setzen:

import java.util.Date;

import java.util.Calendar;

import com.espirit.moddev.uxbridge.api.v1.service.UxbService;

uxbService = context.getConnection().getService(UxbService.class);

//not the start time of the job, but the newest revision

context.logInfo("OLD START TIME: " + context.getStartTime().getTime());

Calendar cal = Calendar.getInstance();

cal.setTime(context.getStartTime());

cal.add(Calendar.MINUTE, -60);

Date modifiedStartTime = cal.getTime();

context.logInfo( "MODIFIED CALENDAR TIME" +modifiedStartTime.getTime());

context.setStartTime(modifiedStartTime);

//not the modified calendar time, but the computed revision for the modified calendar time

context.logInfo("NEW START TIME: " + context.getStartTime().getTime());

uxbService.removeUxbEntriesByTime(context.getStartTime().getTime(), "myObjectType", "elasticSearch");

Hiermit sahen die UXB-Nachrichten gut aus, ich hatte aber das Problem, dass diese einige (in meinem Adapter Pflichtfelder) Felder als null gesetzt hatten. z.B. uuid, path.

Custom Attributes wie

...

uxbService = context.getConnection().getService(UxbService.class);

Map attributes = new HashMap();

attributes.put("uuid", "4712");

attributes.put("path", "/dummy/path");

...

uxbService.removeUxbEntriesByTime(context.getStartTime().getTime(), "myObjectType", "elasticSearch", attributes);

haben leider auch nichts gebracht da man speziell diese reservierten Attribute nicht per Parameter überschreiben darf 😉

-------------------------

WARN  14.03.2016 14:25:17.547 (com.espirit.moddev.uxbridge.service.UxbServiceImpl): Ignoring reserved custom root attribute 'path'.

WARN  14.03.2016 14:25:17.547 (com.espirit.moddev.uxbridge.service.UxbServiceImpl): Ignoring reserved custom root attribute 'uuid'.

-------------------------

Im Endeffekt ist meine derzeitige Lösung dann so, dass ich für "add" und die nachfolgenden "cleanup" UXB-Nachrichten die gleiche startTime habe, und im Adapter alles "<" startTime (wichtig nicht "<=", sonst ist wieder alles weg) lösche.

Grüße,

Alex

0 Kudos

Hallo Alex,

folgende Attribute sind für das korrekte Funktionieren der UX-Bridge relevant und können daher nicht überschrieben werden:

command, createTime, events, finishTime, fullGeneration, language, objectType, path, projectId, projectName, schedulerId, startTime, status, type, uuid

Die Idee (Develoer Doku Kapitel 2.1.4.2  Komplettabgleich ) für das cleanup ist folgende:

  1. Bei der Voll-Generierung werden alle Datensätze neu in das Repository geschrieben.
  2. Bei jedem Datensatz wird im Repository das lastmodified auf die createTime der Nachricht gesetzt
  3. Nach dem alle Datensätze aktualisiert wurden, wird das cleanup gestartet, d.h. es werden alle Datensätze gelöscht, die jetzt nicht neu generiert wurde, bzw. deren lastmodified vor der startTime liegen.

Das sollte sogar funktionieren, ohne die startTime zu ändern.

Gruß

Thorsten

0 Kudos

Hallo Alex,

ist dieses Posting noch aktuell? Benötigst du noch weitere Hilfe oder konnte Thorsten deine Fragen beantworten? In diesem Fall wäre es super, wenn du seine "richtige Antwort" entsprechend markierst.

Viele Grüße

Michaela

0 Kudos

Hallo Thorsten,

im Endeffekt wurde das Problem dann im Adapter gelöst.

Es ist dann vielleicht für andere hilfreich, dass die Methode aus dem Generierungsscript die StartTime zu setzen, nicht funktinoiert:

context.setStartTime(modifiedStartTime);

Grüße,

Alex

0 Kudos