Zum Hauptinhalt gehen

Bug in UX-Bridge Generierung und Cleanup

Zendesk API User

Author: amelnik
Publication Date: 3/14/2016 15:07

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

Tags: cleanup, generate, generierung, ux-bridge, uxbridge

Verknüpfung mit

0

Kommentare

5 Kommentare

Datum Stimmen
  • Zendesk API User
    Author: thmarx - 3/17/2016 8:07

    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
  • Zendesk API User
    Author: amelnik - 3/17/2016 9:23

    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
  • Zendesk API User
    Author: thmarx - 3/17/2016 12:00

    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
  • Zendesk API User
    Author: MichaelaReydt - 3/24/2016 13:36

    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
  • Zendesk API User
    Author: amelnik - 3/25/2016 11:24

    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

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

Sie haben nicht gefunden, wonach Sie suchten?

Neuer Post