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

Question

Question

Best way to ensure web request was sent

Laserfiche Cloud Business Processes
Updated January 7
asked on January 7

What is the best way to guarantee that web request was made (sent) from a forms business process? This is specifically in Laserfiche Cloud. 

It's very edge case, but if the web request doesn't get sent it will cause extra challenges to resubmit. 

It's a two way street - I need send and receive, but for LF purposes I need to guarantee it was sent as best that I can. 

0 0

Answer

SELECTED ANSWER
replied on January 7

Re:

Is writing to the cloud lookup tables the most reliable action from the bp? I am assuming we would have far less potential disruptions from bp > lookup table as opposed to bp > web request?

I can't speak to "reliability" in a statistical sense there, but a Business Process > Lookup Table call doesn't have external dependencies, which seems important here.

I agree that an "explicitly confirm receipt before proceeding" flow like you outlined is the way to go. That could be the "shared table" mechanism, or something simpler like Laserfiche only treating specific HTTP response codes as success and retrying/not proceeding until it gets an HTTP 200 back.

If the business objective is "don't advance the process until we're 100% confident the other side has received and processed the request to avoid complex manual resubmission", you need a mechanism by which the other side can affirmatively tell Laserfiche "I received and consumed the request, you're safe to proceed."

Trying to confirm web requests sends on the Laserfiche side feels like an XY Problem. That's not to say the try/catch mechanism I outlined for sends isn't still worthwhile for reliability/error handling, but a confirmed send isn't an actionable signal for the business logic here. Only a confirmed consumed receive is, so I'd focus on the confirmation mechanism.

1 0

Replies

replied on January 7

Perhaps some sort of try/catch branch with "wait and retry" logic in the catch, and email alert if the retry also fails? You might need to have to have the Forms business process invoke a workflow to get that level of control.

You might need to define the "failed to send" scenarios more clearly for the edge case handling. That clearly includes "Laserfiche outright doesn't attempt to send a request", say from a service outage. But what about a TLS error from an expired certificate on the recipient where Laserfiche tries to send the request but can't establish a TLS session?

0 0
replied on January 7

Hmm good stuff!

Is writing to the cloud lookup tables the most reliable action from the bp? I am assuming we would have far less potential disruptions from bp > lookup table as opposed to bp > web request?

If that's the case and I REALLY want to make it bullet-er proof, I could write to the lookup table with a consumed=no, send the web request, let the other app consume the web request and then update the lookup table via the odata API and flip to consumed=yes. 

The 'other app' can poll the lookup table to look for unconsumed rows.  

I don't know if I ever had a web request not get sent and its far more likely that the other end didn't get it. But if the other app doesn't get the web request it will be an internal staff manual resubmission of a form. 

0 0
SELECTED ANSWER
replied on January 7

Re:

Is writing to the cloud lookup tables the most reliable action from the bp? I am assuming we would have far less potential disruptions from bp > lookup table as opposed to bp > web request?

I can't speak to "reliability" in a statistical sense there, but a Business Process > Lookup Table call doesn't have external dependencies, which seems important here.

I agree that an "explicitly confirm receipt before proceeding" flow like you outlined is the way to go. That could be the "shared table" mechanism, or something simpler like Laserfiche only treating specific HTTP response codes as success and retrying/not proceeding until it gets an HTTP 200 back.

If the business objective is "don't advance the process until we're 100% confident the other side has received and processed the request to avoid complex manual resubmission", you need a mechanism by which the other side can affirmatively tell Laserfiche "I received and consumed the request, you're safe to proceed."

Trying to confirm web requests sends on the Laserfiche side feels like an XY Problem. That's not to say the try/catch mechanism I outlined for sends isn't still worthwhile for reliability/error handling, but a confirmed send isn't an actionable signal for the business logic here. Only a confirmed consumed receive is, so I'd focus on the confirmation mechanism.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...