Workflow UI Message: HTTP Session Serializable Error

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Identity IQ Version: 8.2

Hi all,

I am building a QuickLink launched Workflow that displays a request form to the user, then takes the contents and builds a plan, approval, and manual action.

I would like to display the green “Request Submitted” session message to the user (ideally with the ID), but am encountering an issue with the HTTP Session when the form is submitted

ERROR http-nio-8080-exec-4 sailpoint.api.Workflower:4580 - An unexpected error occurred: No serializer registered for class class org.apache.catalina.session.StandardSessionFacade

I understand that this error occurs when a work item is created and the system attempts to serialize HTTP Session. My workflow is set to transient, however upon submission of the form it progresses to the approval step where this error manifests.

Is there any way I can close or delete the session variable before the workflow advances to circumvent this error? Or is there a way I should be splitting my workflow between its transient half and non-transient half? Or is there simply a better way I am unaware of to display the status messages to end users?

Any help is appreciated. Thanks a bunch.

Below is the snippet of QuickLink XML I am using to pass in the session:

      <entry key="httpSession">
        <value>
          <Script>
            <Source> 

              import javax.faces.context.FacesContext;
              import javax.servlet.http.HttpSession;
              FacesContext fc = FacesContext.getCurrentInstance();
              HttpSession session = (HttpSession) fc.getExternalContext().getSession(true);
              return session;

            </Source>
          </Script>
        </value>
      </entry>

And the Workflow step in which I use the session for the message display:

<Step icon="Default" name="UI Message" posX="255" posY="140">
    <Script>
      <Source> 
                import javax.faces.application.FacesMessage;
                System.out.println("Session is : " + httpSession);

            FacesMessage myMessage = new FacesMessage(FacesMessage.SEVERITY_INFO, "Request submitted successfully: ",null);
            List myMessages = new ArrayList();
            myMessages.add(myMessage);
            httpSession.setAttribute("sailpoint.web.PageCodeBase.sessionMessages", myMessages)
        </Source>
</Script>
<Transition to="Create Plan"/>

</Step>
2

Hi @chris-hogan welcome back

This is a solid problem statement and the snippets help a lot.

What’s actually happening root cause from my view point

You’re not hitting a “session management” issue , you’re hitting workflow persistence + serialization.
•Your workflow starts transient, so nothing is persisted at first.
•The moment you reach an approval (work item), IIQ must persist the WorkflowCase.
•When IIQ persists the case, it serializes workflow variables. Your httpSession variable is a Tomcat StandardSessionFacade, which is not serializable, so the persist step fails with:
No serializer registered for class org.apache.catalina.session.StandardSessionFacade

This aligns exactly with the platform behavior: a workflow remains transient until it reaches an approval step; then it stops being transient and is persisted.

What to avoid and not to do, trying to “close/delete the session” from inside the workflow isn’t the right lever here (and can create side effects like breaking the user’s UI state). The problem isn’t the session existing — it’s storing the session object inside workflow variables that must be serialized.

The fix should be as follows.

Mark the workflow variable that holds the session as transient, so it’s never written to the persisted WorkflowCase.

In the workflow definition, declare the variable like this:

Keep using it only in the UI message step:
set. sailpoint.web.PageCodeBase.sessionMessages
then continue to plan/approval

Optional extra hardening (belt & suspenders): right before transitioning to any approval step, explicitly drop the reference:

httpSession = null;

That ensures that even if someone later removes the transient=“true” attribute by mistake, you’re not carrying a non‑serializable object forward.

Cleaner architecture, if you want this to be bullet‑proof long‑term

If this workflow is going to grow i mean more approvals, retries, background steps, the clean separation is:

  1. Workflow A (UI wrapper / transient only):
    • show the request form
    • build your “Request submitted (ID …)” UI session message
    • then launch Workflow B and end
  2. Workflow B (long‑running / persisted):
    • build plan
    • approvals + manual actions

This keeps “UI/session concerns” out of the persisted workflow state entirely.

avoid future “no serializer” surprises

In any workflow that can hit approvals/work items, avoid storing these as workflow variables unless they’re transient:
• HttpSession, FacesContext, request/response objects
• heavyweight platform objects that don’t serialize cleanly

Check the below if i may missed something

3

Hi Amr,

Thanks so much for your prompt and thorough response! I added httpSession as follows and it resolved the issue:

<Variable input="true" name="httpSession" transient="true">
    <Description>
       The HTTP Session of the user who launced the form
    </Description>
</Variable>

I was unaware that the transient attribute could apply to variables as well the workflow itself. I don’t see it listed here under the Variables documentation:

Editing Workflow XML - SailPoint IdentityIQ

Hopefully it is a supported use case.

Best,
Chris

2 Likes
4

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.