Portals failing after update to 4.0

[Penguin]

I updated the portals to 4.0 and now Switch says that my outgoing Program ID is not valid but it matches my incoming portal so I'm confused. Any help would be appreciated.

Thanks,

[Arthur]

The same thing happens when updating to 5.0.
I have not had time to play around, but my first bet was to recreate the IN / OUT portals from scratch, giving them the same values as you already had.
In our case it is almost a 100, so I reverted back to 3.0 as it was quicker than recreating those.
But I'd check that first.
Please let us know if it worked.

[essexmate]

I've noticed since upgrading to version 6.0 (and I think the same was also happening with version 5.0) that some of our callbacks are failing. Switch Portals is occasionally leaving zip files in this location: C:\Users\username\AppData\Roaming\Enfocus\Switch Server\ScriptData\SwitchPortalsEther (Doing a search for .zip in that location shows up zip files which get stuck).

When this happens, we get an error for the portal saying "unpackJob returned false. Could not unpack. Skipping this file. See previous message for further information." The previous message says "Job ticket does not exist, and could not be restored".

I have tried recreating the portal callback with new values, the error goes away, but eventually returns.

[ThomasDeschamps]

Hello there,
After encountering numerous problem with V3, We decided to take a look at the code from Dominick Peluso, and rewrote it.
Finally we took over the maintenance of Portal app, but the appstore is still not up to date for the new repo for the portal support Here is the new link : https://bitbucket.org/sobookhub2/switch-portal.


Here is the statement before our work (V4 to V6), the Outgoing module Had two major "bug" :

• When the Outgoing try to read a "Zip" in the ether path before it was full written

• When the "zip" file did'nt contain any "job ticket"

Portal V4
We adressed this by two test :

• Check if the file "has arrived" for a delimited time (no evolution in file size)
  If false, throw an alert, and skipp the file until the next test

• Check if the job ticket was present in the zip file
  if not throw an error and skipp file until the next test (repeatidly)

By doing that, Outgoing portal can't entirely crash.

Portal V5
We had a demand from enfocus in order to make it more compliant with older switch version

Portal V6
Solved an issue with the "program ID" field validation wich is fixed since V6

Since the most frequent error we encounteredFor the moment, we did'nt rework the "incoming" element wich is still in the same state since V3.
We'll try to rewrite this for a futur V7 in order to fix the job ticket writting.
Let us now if it answer totally or partially to your problematics and feel free to give us feedback or idea for futur improvement (TrafficLight, outgoing log, bug that we didn't notice...)

[essexmate]

Hi Thomas, thanks for your reply.

Even with version 6, Portals is very buggy. We are seeing zip files getting stuck within Portals folders. When this happens, we get the following errors:

unpackJob returned false. Could not unpack. Skipping this file. See previous message for further information

Job ticket does not exist, and could not be restored

This error gets repeated continually until the zip file is manually removed from the portals folder.

The error is also inconsistent and doesn't occur all the time. It happens with different portal callbacks.

We didn't see any of these errors with version 3.

[gabrielp]

Finally we took over the maintenance of Portal app

the appstore is still not up to date for the new repo for the portal support Here is the new link : https://bitbucket.org/sobookhub2/switch-portal.

Instead of forking the project entirely, could you make contributions to https://github.com/open-automation/switch-portals ?

[ThomasDeschamps]

Hi Thomas, thanks for your reply.

Even with version 6, Portals is very buggy. We are seeing zip files getting stuck within Portals folders. When this happens, we get the following errors:

unpackJob returned false. Could not unpack. Skipping this file. See previous message for further information

Job ticket does not exist, and could not be restored

This error gets repeated continually until the zip file is manually removed from the portals folder.

The error is also inconsistent and doesn't occur all the time. It happens with different portal callbacks.

We didn't see any of these errors with version 3.

Can you Pm me a "zip" file in order to test it?

[mart3223]

Did someone have a solution? I'm currently running on V6 but (working but buggy, a lot of errors in the messages).

[essexmate]

Switch messages says:
unpackJob returned false. Could not unpack. Skipping this file. See previous message for further information
Job ticket does not exist, and could not be restored


Getting lots of zip files getting stuck here:
C:\Users\USERNAME\AppData\Roaming\Enfocus\Switch Server\ScriptData\SwitchPortalsEther


Searching for zip files in the above location and deleting them clears the error in Switch messages. Why are they getting stuck??

Using version 6.0

[ThomasDeschamps]

It's still unclear, but sometime the "Outgoing" portal will fail to make a proper Zip File with all the element needed by the "Incoming".
In your case, it's the jobticket (xml with all your metadata) who are missing.

The current statement is that it's not a "repeatable" bug : If we re-submit exactly the same file and metadata trough the portal, it may not crash.
We are looking actually to fix this but it's not a easy-one due to it's non-repeatability.



It's not a "new" bug since V4 it was already there before.
Version 3 and prior will be stuck in a loop on this file and crash this outgoing until the zip is manually deleted.
The v4 and later version prompt the error on log and is handled by skipping the file and process the next one.

[patej]

Hi,
We've been using Portals (a bit modified version 3.1) quite extensively the past couple of years and have occasionally faced similar problems, especially with writing the zip file. However, we're now in the process of migrating from Portals to the Switch2Switch app (https://www.enfocus.com/en/appstore/pro ... tch2switch) and I recommend you to test that, too.

• If you don't need to transfer job folders, you don't need to pack the jobs before transferring, so that problem is "solved".
• It makes use of Switch's Remote Processing capabilities so there is virtually no delay in transferring jobs from Send to Receive, unlike Portals, which relies on polling the "ether folders".
• Remote Processing means that it can transfer jobs within a single flow and between flows on the same server, but also between several Switch servers.

Today the app got an update to v4, which doesn't anymore require an outgoing connection in the Send element, so it's quite straightforward to replace Portals with it. It has only one "Channel" property, compared to Portals' "Program" and "Channel", but we just converted those to "Portal:Channel" format.

--patrik