Weave Hub

Background

Integration between Weave and third-party applications previously relied upon Weave Link to provide a means of communication between the third party application and the browser running Weave. However, Weave Link was limited in that it required Internet Explorer to be used as the browser. To address this limitation and open up third-party integration in Weave to additional browsers Weave Hub has been developed. Weave Hub is an application that runs on each client PC and provides a communications channel between the browser and the other applications. Weave Hub by itself only supports communications between a browser running the Weave client and Weave Hub. To allow Weave Hub to communicate with other applications additional add-ins must also be installed.

Basic Design

The basic design of Weave Hub is significantly different from that of Weave Link. Weave Link was a component that was installed locally on the client PC and third-party applications used it to directly communicate with Weave. The Weave Link component was used by the third-party applications and would communicate directly with the browser (which is why it was limited to Internet Explorer). Weave Link would take care of locating an existing browser and starting a new browser session if one could not be located and then access the JavaScript code embedded within the Weave application. Weave Hub, however, is an application that runs locally on the client PC and listens for messages and handles the routing of those messages between the appropriate applications. Out of the box, Weave Hub knows how to handle messages sent to and from Weave and, by installing additional add-ins, messages for other applications can also be handled.

Note that currently Weave Hub is supported on 32 and 64 bit Windows but currently only 32 or 64-bit Weave Hub add-ins can be used at one time, and it requires at least version 4.6.1 of the .Net Framework to be installed (which should be installed by default on Windows 10 or later and installed via a Windows Update for Windows 7 since around January 2016). The choice between the 32 or 64-bit installation depends upon the third-party applications that you use, not the operating system or browser. If you run a 32-bit version of a third-party application, even if it's on a 64-bit operating system with a 64-bit browser, then you'll need to use the 32-bit version of Weave Hub and the associated plugins. Note this can be an issue if you run a mix of 32 and 64-bit third-party desktop applications. There is now only one version of the installer and should work on both 32 or 64 bit operating systems.

The diagram below shows parts required for Weave Hub and how the communication between them occurs. 

Open

Weave Hub Installation

Client PC Components

Installation of Weave Hub is performed via a .msi file which only provides options to change the default installation location and whether or not to launch Weave Hub after installation is completed. The installer will, by default, install the core Weave Hub components at C:\Program Files\Cohga\WeaveHub\, and will create a shortcut in the Startup folder to the Weave Hub application so that it's launched each time the user logs in along with a Windows service. Additionally, it creates some registry entries, at HKLM\SOFTWARE\Cohga\WeaveHub. The installation can be performed silently but in this case, it will not be started automatically. The WeaveHub.msi installer must be run as an administrator.

To obtain the required client installer .msi files and install any server bundle updates, you need to download the Interop installer package for your version of Weave from http://downloads.cohga.com/weave/. Once you've downloaded the file you should run the Interop package on the Weave server in the same way you would if you were installing or upgrading Weave.

The Interop installer requires that you provide it with the path where your Weave server instance is installed and that you select the third-party applications you wish to integrate with. Ensure that the server is not running when you perform the installation. Once the Interop installation is complete, any required Weave server bundles will have been installed in the ...\weave\platform\plugins directory, and the required client installer .msi files copied into the ...\weave\interop directory. You can now copy the .msi files from those directories and apply them to the client PC using your internal software distribution processes.

Unless the icon has been hidden, via the right click menu, you should see the following icon in the Windows system tray when the Weave Hub client component is running

Open

Weave Server Components

To provide support to the rest of the Weave client, an updated version of the com.cohga.client.interop bundle, at least version 3.0.0, must be installed in the Weave server. This updated bundle provides code that the third-party components within the client will use to communicate with the Weave Hub. Additionally, the Weave Hub integration must be enabled via a plugin to the client configuration. This can be done by adding the weave.hub plugin to the client as shown below. 

Adding Weave Hub plugin to client configuration

The reason for the authentication requirement is that it's needed for the Weave Hub client component to be matched up with the user that's just opened their browser and started a Weave client.

The Weave Hub client component is what's responsible for doing the actual work of communicating between Weave and the third party systems, and therefore has to be run for each user that is logged in.

When the user then opens a Weave client in a browser (with the Weave Hub plugin enabled) it needs to "connect" to the Weave Hub client component so that it can communicate with it about the different tasks it needs it to perform in relation to interacting with different third party systems. But how does it do that as there are multiple instances of the client component running, one for each logged in user?

This is where the Weave Hub service comes in, it is started when the server starts up and listens for Weave Hub client components to start. Then when the user logs in and the Weave Hub client component is started, it registers itself with the Weave Hub service, providing it with the username of the user who started the Weave Hub client component, and the service gives the Weave Hub client component its own web socket port to listen on (essentially a random port number) and records the port number against the username.

Then when the Weave client starts, it connects to the Weave Hub service on a known web socket port number, 51270, and asks it what port the Weave Hub client component it should be talking to is listening on. If this isn't on a multi-user system there will only be one available Weave Hub client component running so even if the browser doesn't know who the user is, the service will assume that the only running Weave Hub client component is the one to use. It will let the browser know the port number that that Weave Hub client component is listening on and the Weave client will then commence communicating with the Weave Hub client component via web sockets on that port number.

But if there are multiple users logged in then there are multiple Weave Hub client components registered with the Weave Hub service and the Weave Hub service won't know which one to redirect the browser to. This is why in a multi-user environment Weave has to have the user authenticated. Therefore it knows what their Windows username is so that when the browser talks to the Weave Hub service it can ask for the web socket port for a specific instance of the Weave Hub client component that is theirs, the one that was registered against the username recorded when the Weave Hub client component started.

If the username reported by Weave is different from that reported by Windows, either because the Weave user is anonymous or because they’re logged in with a different username from their Windows account name, then there will be a problem since the Weave Hub service won’t be able to find the correct Weave Hub client to redirect the browser to. This is why you need to ensure that the About page of the Weave Hub client component and the /weave/whoami page agree on who the user is.

Weave Hub Add-ins

Authority

Client PC Components

The Authority Weave Hub add-in is installed via a .msi file and only provides the option to change the installation directory, which defaults to C:\Program Files\Cohga\WeaveHub\Authority\. The installer also creates some registry entries to register the add-in with Weave Hub.

The Authority integration requires a program to be installed on the client PC which is called by the Authority add-in to initiate a request sent from Weave to Authority. This program should be provided by the Authority software vendor and setup by your IT department. The location of this program is provided by setting the ulaunch property in the Weave Authority configuration as shown below. 

Partial Authority configuration sample showing ulaunch being set

See the existing Authority integration page for information on what other settings can be included above.

Integration from Authority to Weave is now controlled by a new program called AuthorityWeave.exe, installed by the Weave Hub Authority add-in .msi file at C:\Program Files\Cohga\WeaveHub\Authority\, which when called will trigger Weave to perform the actions required by Authority. And the AuthorityWeave.exe should be called from the Authority program Setup_customer.bat.

Example Setup_customer.bat calling AuthorityWeave

The AuthorityWeave.exe program supports a single command line parameter which is the URL used to start Weave if it is not already running. If the parameter is not provided, by Setup_customer.bat for example, then the startup URL will be determined by the registry value HKML\SOFTWARE\Cohga\WeaveHub\Authority\StartURL. If this is not set, the Weave must already be running for the integration to work.

Weave Server Components

For the client to utilise the new Weave Hub integration, the com.cohga.weave.authority bundle must be updated, to at least version 2.0.0. The updated bundle provides the same functionality as the previous version of the Authority integration but uses the Weave Hub API to perform the communications.

Note that no changes are required in the client configuration to utilise the new integration. The client actions com.cohga.authority.Send, com.cohga.authority.HandleNeighbourNotification, etc, will determine if the new Weave Hub API is available and use that otherwise they will fall back to the older methods.

Pathway

Client PC Components

The Pathway Weave Hub add-in is installed via a .msi file and only provides the option to change the installation directory, which defaults to C:\Program Files\Cohga\WeaveHub\Pathway\. The installer also creates some registry entries to register the add-in with Weave Hub.

In addition to the Weave Hub add-in, the installer also installs and registers the component required for Pathway to communicate with Weave, Pathway.COMGIS (either Pathway.COMGIS1 or Pathway.COMGIS2). The Pathway.COMGIS component works by sending messages to Weave Hub, which Weave Hub then passes on to the Weave client for processing.

The Pathway integration components must also be installed on the client, this is supplied by Infor and should be located at ...\msc\Pathway.Integration.Setup.exe at your Pathway installation location (which is generally a network share).

Weave Server Components

For the client to utilise the newer Weave Hub integration the com.cohga.weave.pathway bundle must be updated, to at least version 3.0.0. The updated bundle provides the same functionality as the previous version of the Pathway integration but uses the Weave Hub API to perform the communications. To utilise the updated actions in the client, the id of the actions need to be updated. Previously, for example, the action for sending the current selection to Pathway had the id of com.cohga.pathway.Display, and then com.cohga.pathway2.Display (when the actions were updated from using ActiveX to JavaScript). If you wish to utilise Weave Hub, the id will be com.cohga.pathway3.Display. Note that as was the case previously, the Pathway actions can be added directly to a toolbar or added within their own menu.

Adding some Pathway actions to the client

Pathway server configuration

Pathway Configuration

Pathway must be configured to use the COM method of calling the GIS application and must use the Pathway.COMGIS2 component to perform that integration, which is outlined at the bottom of this page. Pathway.COMGIS1 was used by Weave Link, and by using Pathway.COMGIS2 it allows both the older Weave Link and the newer Weave Hub to be installed concurrently.

Unlike the Weave Link Pathway integration, the URL configured in Pathway GIS Product Maintenance and used to launch Weave, should just be the Weave URL. Weave Link required that the URL be prefixed with the title of the Window that Internet Explorer would display when the Weave client was running. This prefix is no longer required for Weave Hub and should be removed. For example:

would become just:

There is no executable required to be configured for the COMGIS based integration so you just need to set the Path for Executable in the GIS Product Maintenance to an existing file (as the form will not let you leave it blank).

TRIM/HP RM/HPE CM

Client PC Components

The Trim Weave Hub add-in is installed via a .msi file and only provides the option to change the installation directory, which defaults to C:\Program Files\Cohga\WeaveHub\Trim\. The installer also creates some registry entries, to register the add-in with Weave Hub.

In addition to the Weave Hub add-in, the installer also installs an executable, TrimWeave.exe, that can be used by Trim to communicate with Weave. The executable will be installed at the default location listed above unless it's changed during installation and can be used in the same way as the previous Weave Link version, which is outlined at the bottom of this page. Like the Pathway integration, the executable just sends messages to Weave Hub which will then forward them on to the browser.

Weave Server Components

For the client to utilise the newer Weave Hub integration the com.cohga.weave.trim bundle must be updated, to at least version 2.0.0. The updated bundle provides the same functionality as the previous version of the Trim integration but uses the Weave Hub API to perform the communications. To utilise the updated actions in the client, the id of the actions need to be updated. Previously, for example, the action for sending the current selection to Trim has the id of com.cohga.trim.Send, and now if you wish to utilise Weave Hub the id will be com.cohga.trim2.Send.

Adding a Trim action to the client

Proclaim

Client PC Components

The Proclaim Weave Hub add-in is installed via a .msi file and only provides the option to change the installation directory, which defaults to C:\Program Files\Cohga\WeaveHub\Proclaim\. The installer also creates some registry entries, to register the add-in with Weave Hub.

In addition to the Weave Hub add-in, the installer also installs and registers a COM object that can be used by Proclaim to communicate with Weave. The name of the COM object is WeaveHubProclaim.MapAutomation and must be registered within Proclaim as the component to call when communicating with a GIS, which is outlined at the bottom of this page. Like the Pathway and Trim integrations, the COM object just sends messages to Weave Hub which will then forward them on to the browser.

Weave Server Components

For the client to utilise the newer Weave Hub integration the com.cohga.weave.proclaim bundle must be updated, to at least version 2.0.0. The updated bundle provides the same functionality as the previous version of the Proclaim integration but uses the Weave Hub API to perform the communications. To utilise the updated actions in the client, the id of the actions need to be updated. Previously, for example, the action for sending the current selection to Proclaim has the id of com.cohga.proclaim.Send, and now if you wish to utilise Weave Hub the id will be com.cohga.proclaim2.Send.

Adding a Proclaim action to the client

Troubleshooting

The Weave Hub components generate logging output that can be captured using the DebugView tool from Microsoft. Having DebugView running while interacting with Weave Hub can capture output that may be useful in troubleshooting issues.

Weave Hub Service

The Weave Hub service, WeaveHub.Service.exe, can also be run directly, as opposed to being started via the Windows Services component, but make sure you stop the service before starting the application. Running Weave Hub directly allows you to see the log output generated as the application starts up, which may provide additional troubleshooting information, and also as the Weave Hub app communicates with the Weave Hub service.

Weave Hub Application

The only log output for the Weave Hub app is via DebugView. It is not possible, like with the Weave Hub service, to run the Weave Hub app as a console application to view the console output.

About

The About page in the Weave Hub app, which can be shown by right clicking on the Weave Hub app in the task bar and selecting About from the menu, contains information about the version numbers of the components that are installed and some other details that will help in troubleshooting.

Hide Icon

The Hide Icon menu entry in the right click menu of the Weave Hub app removes the Weave Hub app icon from the task bar, it does this by writing a registry entry that the app reads on startup to disable the showing of the icon, if you need to restore the icon you should change the value of the ShowIcon key at HKLM\SOFTWARE\Cohga\WeaveHub\Core\ to 1 using the regedit.exe program (hiding the icon sets the value to 0).

Exit

Sometimes it may be useful to stop the Weave Hub app so that missed log messages that occur during startup can be viewed via DebugView. But the Weave Hub app is intended to be running at all times when the user is logged in so, by default, there is no Exit entry in the Weave Hub app taskbar right-click menu. To enable an Exit menu item you can set a registry entry, note that if the Weave Hub app is installed there will already be a registry entry and the required location to show/hide the task bar icon (which can be edited to re-show the icon if it was hidden). The location where the registry entry should created at is HKLM\SOFTWARE\Cohga\WeaveHub\Core\, the key name should be ShowExit and it should be set to a DWORD value of 1 using the regedit.exe program.

Browser

The Weave Hub plugin will output log messages to the browser console, so this is another location to look for output that may help resolve issues.

Support

To help provide suitable log output for a Support ticket, please follow this process:

1. Kill the WeaveHub.Core.exe process via Task Manager.

2. Stop the Weave Hub Service.

3. Ensure that the WeaveHub.Core.exe and WeaveHub.Service.exe processes are not running in Task Manager.

4. Start DebugView or clear the display if it's already running.

5. Run the WeaveHub.Service.exe program in the C:\Program Files\Cohga\WeaveHub\Core directory, it will open a new window.

6. Run the WeaveHub.Core.exe program in the C:\Program Files\Cohga\WeaveHub\Core directory, it will show the icon in the task bar.

7. Start a new browser session and open a Weave client that has the Weave Hub plugin enabled and wait for it to complete its startup.

8. Use the File|Save menu in DebugView to export the log file and send that to the Support team.

9. Stop Debug View.

10. Press any key inside the window that opened when you ran WeaveHub.Service.exe to shut it down.

11. Restart the Weave Hub service.

Microsoft Edge

Because of security restrictions Microsoft has implemented for Edge Weave Hub will not work unless the following command is run as an administrator on each client PC:

Note: recent versions of the Weave Hub installer perform this step when installing the core components.