You are viewing limited content. For full access, please sign in.

Question

Question

Direct Approval mailbox monitored by two Forms servers . . .

Forms Version 10 Administration
Updated October 25, 2019
asked on October 22, 2019

Hi,

I am working with a client whose on-prem system uses both a production and sandbox environment, each with their own Forms server.  We are setting up Direct Approval for use by some tasks in some Forms processes.  Installed version is 10.3.

Can we use the same email mailbox to monitor Direct Approval actions from multiple Forms servers?

On the surface, I would expect this is OK as the XML headers should be unique.  But we have encountered a few unexpected errors, particularly in the form of an email reply to an attempted Direct Approval.  The reply message has the subject line "Invalid email approval" and body text "The email approval (action Approve) failed. Either the task has already been performed or you cannot perform approval actions."

Any thoughts or experiences would be much appreciated.

Best regards, ...... Steven.

 

0 0

Answer

SELECTED ANSWER
replied on October 25, 2019

The Forms server expects the mailbox to be unattended, so it only looks at unopened messages when it pulls the list to process. With 2 servers pulling the same mailbox, you're likely to have the wrong Forms server open the message. If server A sends a document for approval, but the incoming message is processed by server B, you get the error you're seeing ("I don't have this task, probably somebody already did it"). Since server B opened the message, server A will never get it, so the task will wait forever though the user performed the action.

This configuration is not supported.

1 0

Replies

replied on October 23, 2019

Hi Steven,

Is there any particular reason they don't use different emails for each environment? Connecting non-Prod services to Prod resources usually has more potential for trouble than it's worth.

I always specify separate notification, Forms approval, and Email Archive Service emails for at least Prod and non-Prod envs.

E.g.

Prod:

  • lf-notifications@company.com
  • lf-approvals@company.com
  • lf-archive@company.com

Test:

  • lftest-notifications@company.com
  • lftest-approvals@company.com
  • lftest-archive@company.com

Dev:

  • lfdev-notifications@company.com
  • lfdev-approvals@company.com
  • lfdev-archive@company.com
0 0
replied on October 25, 2019 • Show version history

Hi Samuel,

I think your suggestion is a good one.  In the case of Direct Approval, it's not as simple as a "no-reply" email address - the address requires an AD service account and a real mailbox for monitoring.  Not a huge deal, but we were trying to minimize the number of service accounts to maintain.

I was also interested in *why* it wasn't working.  As best I can tell, it looks like the XML headers do keep uniqueness intact, but the breakdown is due to the polling interval.  The routine must use either the timestamp or the "read/unread" attribute to limit the population of emails to monitor.  So, if one server has hit the polling trigger and checks the mailbox, then when the next server hits its polling trigger, it appears that some messages have already been checked (and the opportunity arises to miss processing some Direct Approval actions).

If someone at Laserfiche can fill in the blanks and confirm or correct my understanding of how Direct Approval works at the server level, that would be great.  Either way, we'll move toward limiting mailboxes to one monitoring server.

Thanks again for the input, Samuel.

Best, .... Steven.

0 0
SELECTED ANSWER
replied on October 25, 2019

The Forms server expects the mailbox to be unattended, so it only looks at unopened messages when it pulls the list to process. With 2 servers pulling the same mailbox, you're likely to have the wrong Forms server open the message. If server A sends a document for approval, but the incoming message is processed by server B, you get the error you're seeing ("I don't have this task, probably somebody already did it"). Since server B opened the message, server A will never get it, so the task will wait forever though the user performed the action.

This configuration is not supported.

1 0
replied on October 25, 2019

Hi Miruna,

Thanks for the reply.  That makes sense and matches my anecdotal test conclusions.

Best, .... Steven.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...