Details

      Description

      Implement logic for detecting offline and upgraded peers, render result in List Applications page (synchronous/background/ajax?)

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            evzijst Erik van Zijst added a comment - - edited

            It's necessary to know whether a peer is online or offline, so we can prompt the user with the appropriate actions ("relocate server", "upgrade server"). This is not something we can do in APL in an application-independent way (some apps may not serve anything on their baseUrl, may have a proxy-server / load balancer / etc that still respond even though the app itself is offline, or a non-apl app may not be accessible at all).

            We should therefore add a getStatus() method to the SPI for app types to implement.

            The contract for detecting upgraded peers then becomes:

            if (peer is OFFLINE)
            {
              display "server offline" and "relocate" icon. "relocate" starts Relocate Wizard
            }
            else if (ServerID has changed)
            {
              if (peer UAL.version >= 3)
              {
                peer must be upgraded -> start full Upgrade Wizard
              }
              else
              {
                peer must have downgraded from UAL to non-UAL -> start ServerID Change Wizard
              }
            }
            
            Show
            evzijst Erik van Zijst added a comment - - edited It's necessary to know whether a peer is online or offline, so we can prompt the user with the appropriate actions ("relocate server", "upgrade server"). This is not something we can do in APL in an application-independent way (some apps may not serve anything on their baseUrl, may have a proxy-server / load balancer / etc that still respond even though the app itself is offline, or a non-apl app may not be accessible at all). We should therefore add a getStatus() method to the SPI for app types to implement. The contract for detecting upgraded peers then becomes: if (peer is OFFLINE) { display "server offline" and "relocate" icon. "relocate" starts Relocate Wizard } else if (ServerID has changed) { if (peer UAL.version >= 3) { peer must be upgraded -> start full Upgrade Wizard } else { peer must have downgraded from UAL to non-UAL -> start ServerID Change Wizard } }
            Hide
            tpettersen Tim Pettersen added a comment -

            Nice, looks good to me.

            Show
            tpettersen Tim Pettersen added a comment - Nice, looks good to me.
            Show
            evzijst Erik van Zijst added a comment - https://extranet.atlassian.com/display/~evzijst/AppLinks+Upgrade+Application+Link+workflow
            Hide
            fschmitz Felix Schmitz (Inactive) added a comment -

            For the following scenario: When relocating an application that is NON-UAL this can then lead to a server id change and this can then mean after doing the "relocation" (changing the url i assume), it will lead to a server id change which then will trigger this server id change wizard. I think from a user perspective it would be good if this is not a second wizard, just one transaction.

            Show
            fschmitz Felix Schmitz (Inactive) added a comment - For the following scenario: When relocating an application that is NON-UAL this can then lead to a server id change and this can then mean after doing the "relocation" (changing the url i assume), it will lead to a server id change which then will trigger this server id change wizard. I think from a user perspective it would be good if this is not a second wizard, just one transaction.
            Hide
            evzijst Erik van Zijst added a comment -

            I think from a user perspective it would be good if this is not a second wizard, just one transaction.

            Yes, agreed. We should attach the upgrade wizard to the relocation wizard.
            I'll mock out those scenarios.

            Show
            evzijst Erik van Zijst added a comment - I think from a user perspective it would be good if this is not a second wizard, just one transaction. Yes, agreed. We should attach the upgrade wizard to the relocation wizard. I'll mock out those scenarios.

              People

              • Assignee:
                evzijst Erik van Zijst
                Reporter:
                evzijst Erik van Zijst
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 6 hours
                  6h
                  Remaining:
                  Remaining Estimate - 6 hours
                  6h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified

                    Who's Looking?