Hi all, Iโm still in the process of getting familar with appsheet automation processes but I have been having difficulty getting one of them to work. Itโs a webhook workflow that we have been developing for some time. We originally created this in test apps as a workflow, but was still in development when the automation function was deployed.
It seems as though each time I create and test the process it works perfectly, but I have tried deploying it 3 times now and it keeps breaking or just partially functions?
I donโt feel confident enough in the process to deploy it again. For example, I tried to complete the process this morning and received an error in the monitor app - pictured below.
And then tried again a few minutes later and the BOT worked as expected. See below two operations today.
I donโt want to deploy this BOT in live projects because it hasnโt proven to be stable?
Most of the time when it doesnโt work I donโt get any error feedback in the monitor app.
How can it go from working to broken on a day to day basis like this?
I will attach screenshots of the automation below if there is anything Iโm doing incorrectly. I have had communication with support heavily during the creation process.
BOT:
Material Added:
BODY:
{
โActionโ: โAddโ,
โPropertiesโ: {
โLocaleโ: โen-GBโ,
โLocationโ: โ48.220599, 16.239976โ,
โTimezoneโ: โGMT Standard Timeโ
},
โRowsโ: [
<<START: SELECT([Related Material Take Offs][Line Reference],IN([Line Reference],[Request Material]))>>
{
โOrder Noโ:โ0โ,
โLine Referenceโ:"<<[Line Reference]>>",
โMech/Elecโ:"<<[Mech/Elec]>>",
โRequested Dateโ:"<<TODAY()>>",
โLocation Areaโ:"<<[Block]>>",
โRequest Typeโ:โDraw Offโ,
โSub-Areaโ:"<<[Level]>>",
โTake Off Groupโ:"<<[Take Off Group]>>",
โProduct Groupโ:"<<[Product Group]>>",
โProduct Sub-Groupโ:"<<[Product Sub-Group]>>",
โProductโ:"<<[Product]>>",
โProduct Codeโ:"<<[Product Code]>>",
โQty Requestedโ:"<<IF(ISNOTBLANK([Required Qty]), [Required Qty], [Take Off Qty])>>",
โQty Orderedโ:"<<IF(ISNOTBLANK([Required Qty]), [Required Qty], [Take Off Qty])>>",
โUnitโ:"<<[Unit]>>",
โRequested Byโ:"<<[Requested By]>>",
โDate Requiredโ:"<<[Take Off Group].[Date Required]>>",
โRequested Delivery Timeโ:"<<[Take Off Group].[Required Start Time]>>"
}
<>
]
}
Update Status:
BODY:
{
โActionโ: โEditโ,
โPropertiesโ: {
โLocaleโ: โen-GBโ,
โTimezoneโ: โGMT Standard Timeโ
},
โRowsโ: [
<<START: SELECT([Related Material Take Offs][Line Reference], IN([Line Reference],[_THISROW].[Request Material]))>>
{
โLine Referenceโ: โ<<[Line Reference]>>โ,
โRequest Statusโ: โRequestedโ
}
<>
]
}
Reset Material List:
Because the error message says that it is a time out issue, the โproblemโ is likely that your process can vary from short enough to taking too long. If you look at like sync times, they can vary even on the same device with no changes by, in my case, like 30%+.
Can I ask why you use a webhook to do the datachange? Is this table not in the base app?
Yes it is, should I use the Reset on edit options within the column itself instead of the webhook?
In my humble opinion, new BOT is not stable enough to move to Production, bunch of stuffs should be addressed and improved before that.
I hope Appsheet/Google team will reconsider their schedule to transform workflow onto Automation rather than starting it now.
After Google aquition, we are not sure if users voice is reaching to them, so I become speachless โฆ
If the transformation from workflow to Automation happens now, I bet the bunch of issues would arise and we , all app creators would be in troubles for sure.
This is another example.
How does my exisiting workflow will be transformed while the new bot configulation does not have target table seeting for scheduled event?
If it is transformed, i m pretty much sure the new bot (App) will be broken.
Totally agree. We as users were very happy with the Workflow process. It was simple to implement, did what we needed and was reliable. Additional functionality is great but only if it has been thoroughly tested before implementation. I really donโt understand the rush to implement these buggy Bots. Put in Beta and let us as users test it.
These are the execution times reported in the monitor yesterday from the two different tests.
Your JSON body expression for select coupled with nested IN () expression. This is one of the most โheaviestโ expresion among other in Appsheet. If your table is large enough, it takes sometime, wihch may result in timeout error.
This is what I noticed.
Attn @prithpal @Dan_Bahir @praveen
This may be unrelated but since youโre getting a โtook too long to processโ error you might be impacted by the same issue weโre having. TL;DR recent drop in performance is causing some of our processes to fail.
If it worked previously but only started having issues in the past several days, it could be related.
Did you get a change to look at the performance analyzer to understand which parts of your execution take the most time ? If there are expressions that take long to compute they might exceed the timeout under some system conditions.
If you can use a data-action instead of a webhook that is preferred.
What is defined as too long? How much time do we have? What is timeout set to?
The reason we changed to a webhook was because action was taking too long. Was taking half an hour to add 50 rows to a table. The webhook takes about a minute when it actually works.
User | Count |
---|---|
43 | |
29 | |
25 | |
23 | |
13 |