Questions & Answers

[phillip_austerf]

Hallo zusammen,

ich habe eine Frage bzgl. eines Arbeitsbalaufs "generate Partly" im WebClient.

Mein Arbeitsablauf verwendet ein Formular, welches im WebClient auch angezeigt werden soll. Hier kann der User eine Seite/Folder auswählen, welcher dann in ein Generierungsskript übertragen werden soll.

Im JavaClient gibt es hier keine Probleme, jedoch im WebClient.

Es scheint, als würde der Arbeitsablauf noch am Startelement des Ablaufs hängen bleiben. Das Formular (also Teil meines Scripts) wird jedoch korrekt angezeigt.

Gibt es hier eine besondere Einstellung, welche ich wählen muss?

Hier der Code:

import de.espirit.firstspirit.access.store.templatestore.WorkflowScriptContext;

import de.espirit.firstspirit.access.store.IDProvider.UidType;

import de.espirit.firstspirit.access.store.sitestore.PageRef;

import de.espirit.firstspirit.access.store.sitestore.SiteStoreFolder;

import com.idmedia.fs.publisher.Publisher;

wsc = (WorkflowScriptContext) context;

storeElement = wsc.getWorkflowable();

pData = wsc.showForm();

if (pData != null)

{

    try

    {

        pElem = pData.get(null, "st_ref");

        if (pElem != null)

            storeElement = pElem.get().get(); // FormData.TargetReference.IDProvider

    }

    catch(Exception x)

    {

        storeElement = null;

    }

}

OperationAgent operationAgent = wsc.requireSpecialist(OperationAgent.TYPE);

RequestOperation pRequestOperation = operationAgent.getOperation(RequestOperation.TYPE);

pRequestOperation.setKind(RequestOperation.Kind.INFO);

pRequestOperation.setTitle("Generate Partly");

pRequestOperation.perform("do transition done");

context.doTransition("Final");

Viele Grüße,
Phillip.

[phillip_austerf]

kurzer Nachtrag:

Die Rechte sind definiert für die einzelnen Schritte; Berechtigung: everyone; Start automatisch über Rechte.

[tklein]

Hallo,

das nichts passiert deutet ja auf eine Exception hin. Scripte in Workflows sollten immer mit einem Try{}-catch(Exception e) {context.goToErrorState("Fehler", e); umschlossen werden. Im WF-Modell sollte eine Error Status eingebaut werden. Dann sollte man vorher die die Fehlerinformationen loggen oder aber vom ErrorState ausgehend eine Aktivität starten, die aus der WF Session die vorhanden Fehlerinfomationen ausliest. In diesem Falle würde ich zu ersterem tendieren zu debug zwecken. Für den Einsatz bei Redakteueren wäre letzteres empfehlenswert, da sie den Fehlerstatus sehen und dann noch handeln können, z.B: zuweisung an jemanden, der dann eine Mail mit den Fehlerinformationen bekommt.

Viele Grüße

Tobias

[phillip_austerf]

Hallo,

ich habe dies nun einmal umgsetzt, aber der Arbeitsablauf bleibt leider dennoch wieder beim Startelement stehen; ich kann mittels

WorkflowScriptContext.showForm() lediglich Inhalte speichern, nicht aber ausführen.

Selbst wenn ich nach dem Anzeigen des Forms mittels  context.doTransition(....) zum Ende gehe wird der Arbeitsablauf immer auf dem Startelement stehen bleiben.

Woran kann das liegen? Es scheint schlicht, als würde es nach showForm() im WebClient nicht weitergehen.

Viele Grüße,
Phillip.

PS: Hier nun aber einmal der angepasste Code:

import de.espirit.firstspirit.access.store.templatestore.WorkflowScriptContext;

import de.espirit.firstspirit.access.store.IDProvider.UidType;

import de.espirit.firstspirit.access.store.sitestore.PageRef;

import de.espirit.firstspirit.access.store.sitestore.SiteStoreFolder;

import com.idmedia.fs.publisher.Publisher;

wsc = (WorkflowScriptContext) context;

storeElement = null;

pData = null;

bError = false;

try

{

    storeElement = wsc.getWorkflowable();

    pData = wsc.showForm();

}

catch(Exception e)

{

    bError = true;

    pData = null;

    storeElement = null;

}

if (pData != null && bError == false)

{

    try

    {

        pElem = pData.get(null, "st_ref");

        if (pElem != null)

            storeElement = pElem.get().get(); // FormData.TargetReference.IDProvider

    }

    catch(Exception x)

    {

        storeElement = null;

    }

}

if (storeElement != null)

{

    Publisher pPublish = new Publisher(context);

    pPublish.publish("generate partly [DE]", storeElement);

    if (storeElement instanceof SiteStoreFolder)

        pPublish.publishRemoteReferences((SiteStoreFolder)storeElement, "generate partly", "remoteMedia");

    else if (storeElement instanceof PageRef)

        pPublish.publishRemoteReferences((PageRef)storeElement, "generate partly", "remoteMedia" );

}

try

{   

    if (bError == false)

        context.doTransition("Final");

    else

        context.doTransition("Error");

}

catch(Exception x)

{

    context.goToErrorState("Error", e);

}

[tklein]

Hm das try catch mit dem gotoErrorState() muss anz aussen rum, die inneren catches sollten weg oder spezifiziert werden, sonst können ausserordentliche Exceptions ja nicht im Error Status enden.

Ein Error Status hat keine keine eingehenden Transtionen sondern nur ausgehende...

[phillip_austerf]

Ich habe das nun so umgestellt aber es ändert sich nichts am Verhalten.

Ist dies ein gewollter Effekt von showForm()? Oder gibt einen anderen (richtige) Weg?

Viele Grüße,
Phillip Austerfield.

[tklein]

Nein das ist natürlich kein gewollter Effekt Bitte mal so probieren (ungetestet):

import de.espirit.firstspirit.access.store.templatestore.WorkflowScriptContext;

import de.espirit.firstspirit.access.store.IDProvider.UidType;

import de.espirit.firstspirit.access.store.sitestore.PageRef;

import de.espirit.firstspirit.access.store.sitestore.SiteStoreFolder;

import com.idmedia.fs.publisher.Publisher;

wsc = (WorkflowScriptContext) context;

storeElement = null;

pData = null;

bError = false;

try

{

    storeElement = wsc.getWorkflowable();

    pData = wsc.showForm();

if (pData != null )

{

        pElem = pData.get(null, "st_ref");

        if (pElem != null)

            storeElement = pElem.get().get(); // FormData.TargetReference.IDProvider

}

if (storeElement != null)

{

    Publisher pPublish = new Publisher(context);

    pPublish.publish("generate partly [DE]", storeElement);

    if (storeElement instanceof SiteStoreFolder)

        pPublish.publishRemoteReferences((SiteStoreFolder)storeElement, "generate partly", "remoteMedia");

    else if (storeElement instanceof PageRef)

        pPublish.publishRemoteReferences((PageRef)storeElement, "generate partly", "remoteMedia" );

}

context.doTransition("Final");

}

catch(Exception e)

{

     context.logError(e.getMessage(), e);

    context.goToErrorState("Error", e);

}

was macht den der Publischer? Wenn der den Thread blockiert wird die Transtion evtl. erst verspätet geschaltet.

[phillip_austerf]

so, jetzt ist es klar.

Das Problem lag leider wirklich im Publisher.

Wir verwenden ein remote Media Projekt und ich starte über den Publisher nicht nur die Generierung im eigenen Projekt sondern füge auch alle referenzierten remote Medien in den generate Partly Auftrag des Remote Projektes und führe diesen Task aus.

Die Exception, die geworfen wird ist nun

Target exception: de.espirit.firstspirit.client.io.SessionAlreadyBoundException: Session already bound to project 'Master [EN|DE|FR|IT] PROD'! You have to call unbindSession() first.

Ist dies überhaupt über den WebClient möglich?

Viele Grüße,

Phillip.

[tklein]

Der Fehler kommt mir bekannt vor (habe so ziemlich das selbe gebaut)

Welche Connection wird benutzt? Für Aktionen im RemoteProjekt sollte auch die RemoteConnection benutzt werden.

Viele Grüße

Tobias

[phillip_austerf]

Hm, ich verändere die Connection nicht, sondern greife über den UserService auf das RemoteProject zu:

WorkflowScriptContext m_pContext

UserService pUserService = m_pContext.getUserService().getRemoteUserService(sSymName);

Project pProject = pUserService.getProject();

Und dann kann ich über pProject auf die Publizierungsaufträge zugreifen.

Wie sähe denn die alternative aus? Gibt es dazu eine Doku?

Viele Grüße,

Phillip.