Work around for the 20.3 change to PSOS

I think i found a work around to the 20.3 bug with PSOS using DAPI or XML with SimpleQ - put this in the OttoReciver Script. You may need to add a list of files that need to be opened prior to PSOS. In Addition to a few global variable file references. There may be more errors in the log for the failed perform script (the doesn’t exist) used to force open the file.

More testing is needed please report your findings!

1 Like

Was there any further better approaches to this?

I just setup a new webhook to a different file but now I can’t seem to get it to authenticate to the file not sure if I need to restart the SASE I’ve already booted the webhook dAPI user but that didn’t seem to work.

Hi Stephen

Do you have a link to the report of the bug. Has Claris confirmed it?

Thanks

Todd

I thought I submitted a bug report about it to ETS or even posted it on the community I can’t seem to find it. There was some discussion about it in a few threads.

@corn mentioned he was reworking that logic curious if there is any new revelations?

I don’t think there have been. But I’ll check with him

Todd

I believe my work around still works, in my last migration I didn’t pay close enough attention to my external file references I had added additional files to my list of files but didn’t add corresponding number of $$ref#.

Although this method is working since originally implemented I do see equal number of errors for forcing open the file by calling a script that doesn’t exist. For each webhook received.