Skip to main content

Arbeitsablauf WebClient - Workflow stoppt nach Formulareingabe

Zendesk API User

Author: phillip_austerf
Publication Date: 8/13/2013 10:59

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.

Tags: fs5.0, generation, script, webedit, workflow

Related to

0

Comments

10 comments

Date Votes
  • Zendesk API User
    Author: phillip_austerf - 8/13/2013 11:00

    kurzer Nachtrag:

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

    0
  • Zendesk API User
    Author: tklein - 8/13/2013 12:50

    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

    0
  • Zendesk API User
    Author: phillip_austerf - 8/13/2013 13:37

    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);

    }

    0
  • Zendesk API User
    Author: tklein - 8/13/2013 13:46

    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...

    0
  • Zendesk API User
    Author: phillip_austerf - 8/13/2013 14:10

    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.

    0
  • Zendesk API User
    Author: tklein - 8/13/2013 14:20

    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.

    0
  • Zendesk API User
    Author: phillip_austerf - 8/13/2013 15:15

    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.

    0
  • Zendesk API User
    Author: tklein - 8/13/2013 16:01

    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

    0
  • Zendesk API User
    Author: phillip_austerf - 8/14/2013 8:39

    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.

    0
  • Zendesk API User
    Author: tklein - 8/14/2013 13:23

    okay ein letzter versuch meinerseits:

    connection = wFSContext.getConnection().getRemoteConnection(configuration);

    final Project remoteProject = connection.getProjectByName(projectName);

    wie wird der schedule entry geholt? AdminService über die connection?

    Wenn das nicht hilft  muss ich leider passen, dann müsste man sich das im Detail ansehen.

    Viele Grüße

    Tobias

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post