edgeCore is a new platform from the ground up and in concept carries over many features from enPortal / AppBoard along with completely new approaches. Consult the Feature Matrix for a quick overview of enPortal / AppBoard features and how they map to edgeCore features.
Due to the product differences, migrating from enPortal / AppBoard cannot simply be a case of exporting a backup (archive) from the old system and have this load and work in edgeCore. This document outlines a migration process and items for consideration when migrating to edgeCore.
This section highlights the key differences and similarities between enPortal / AppBoard and edgeCore.
|enPortal / AppBoard Component||enPortal / AppBoard Concept||edgeCore Component||edgeCore Concept||Differences / Similarities|
|Both||Accounts (Domains, Users, and Roles)||edgeCore||(same)||Domains and Users are basically the same between both products. Users belong to a single domain and users can be managed via the embedded account controller, or via external LDAP (including Active Directory).Roles are also similar in that a user may be a member of one or more roles. The differences are that in enPortal/AppBoard a user is only ever represented by a single role when logged in, and they are able to switch between roles via the role selector. In edgeSuite a user’s display is a combination of all roles, and there is no role selector. The main implication of this is a user will see the aggregate of all content assigned to them from all roles when logged into edgeSuite. There is also a special AllUsers role that all users are automatically a member of. Also in edgeSuite roles cannot be assigned to domains, and Credentials can only be assigned at the global, domain, or user level – not to roles.|
|Both||Content Provisioning||edgeCore||Provisioning||Although there is overlap, enPortal and AppBoard use different approaches when it comes to managing content and how this is provisioned to users. In edgeCore the approach is unified along the following model: – Content is managed in the Content Tree in the form of Folders and Pages. This is for organizational purposes, but also once provisioned to a user, the (visible) structure will be realized in the form of the user’s navigation menu. In other words, Folders and Pages can be visible or hidden. – Provisioning content can be done by assigning parts of the Content Tree to Domains or Roles. It is not possible to assign content directly to a user. – The navigation menu a user sees when logged into the product is an aggregate of all provisioned content and the visible nodes. Folders appear as sub-menus and Pages as selectable items. – Navigation via user interaction with a Page (Switch-to-Page action) results in a dynamically generated “path” and breadcrumbs shown – however, access to that page is explicit and must have been provisioned otherwise access is not permitted.|
|Both||Login Page||edgeCore||Login Page||Both enPortal/AppBoard and edgeCore support configurable login pages via HTML/CSS. The main difference is with the ability to configure pre-authentication server execution (via JSP in enPortal/AppBoard) along with custom authentication flows. For assistance with this in edgeCore, please contact Support.|
|AppBoard||Themes (Theme Manager)||edgeCore||Themes||edgeCore supports themes via CSS with the future intention to add support for a theme editor to ease the process of building themes. The currently supported method is to start with a system shipped theme, copy to the custom theme location, and add override rules to style as desired. This new theme can then be registered and becomes available when configuring the global theme or via user preference.|
|enPortal||Look and Feel (LAF)||edgeCore||Themes||(see above “Themes”)|
|enPortal||Product Integration Module (PIM)||edgeWeb||Web Adapter||In edgeCore a single web-adapter will support all versions of the application being integrated. The version number in the web-adapter name represents the release of the adapter.|
|enPortal||Target||edgeWeb||Connection||Basically the same; contains the scheme, host, port, and whether to use an external proxy.|
|enPortal||Channel Type||edgeWeb||Feed||Basically the same; a feed type corresponds to a channel type, and each feed instance provides for configuration such as setting the starting URL and which rule file should be used.|
|enPortal||Channel||edgeWeb||Visualization||In enPortal, a Channel represents a frame on the screen that displays proxied web content. In edgeCore, this is referred to as a Visualization. This same term (Visualization) is also used for a frame of data-based content (known in AppBoard as a Widget).|
|enPortal||Single-Sign-On tokens||edgeCore||Credentials||edgeCore has a generic mechanism for managing Credentials that applies for both web-content connections and data connections. Credentials are of a particular type such as username + password, and Web (or Data) Adapters may introduce their own types if needed. When configuring a connection the credentials could be either Static or Variable. Static credentials are provided directly as part of the connection configuration. In this scenario, everyone accessing the content would be using the same credentials and this is more typically the case when accessing data sources. More likely for web-content, Variable credentials will be used. In this scenario, a reference is made to a system managed credential which could resolve to Global, Domain, or User specific values depending on how it is configured. The most specific value takes precedence just as with enPortal SSO tokens. A benefit here over enPortal is that the system-managed credentials are not tied to a host+port as with enPortal. They are associated with connections via configuration so that a single system managed credential could be used for multiple connections if that happens to apply. edgeCore also allows for credential expressions in order to support pass-through authentication (e.g. password used by user to log in to edgeCore is passed through when authenticating to a particular connection).|
|AppBoard||Data Adapter||edgeData||Data Adapter||AppBoard does not have any additional data-adapters other than those included with the base product. For migration purposes the built-in data connection types need to be considered. Refer to the Feature Matrix.|
|AppBoard||Data Source||edgeData||Connection||Data Sources and Connections are very similar and encapsulate the connection information with an external data source. The main difference is that Data Sources also include configuration on what to fetch from the source, this defined the Entities (Data Source Entities) available from that source. Sometimes this was one-to-one with the source, but other times it was one-to-many such as with the DB source which allowed for multiple SQL queries to be configured. In edgeCore, the configuration of what to fetch from a particular connection is handled via separate Feeds. For example, the edgeData equivalent of a DB source with 3 queries would be a DB Connection and 3 Feeds. Also note that credentials for Connections are managed using the new Credentials system (refer to Credentials above).|
|AppBoard||Data Source Entity||edgeData||Feed||(see above “Connection”)|
|AppBoard||SHIM||edgeData||Variables / Expressions||AppBoard Data Source Entities are frequently configured with the use of SHIM expressions to incorporate Session Variables, Query Parameters, or access to other system/session related information (such as the User’s role). In edgeCore, Credentials are used to manage connection credentials, Secured Variables (secVars) are used to provide session type information, Node Variables (nodeVars) are used to pass information upstream in the data pipeline, and Page Variables (pageVars) are used in page interaction and for mapping to upstream nodeVars.|
|AppBoard||Data Collection||edgeData||Feed / Transform||Data Collections are instances of a Data Source Entity, potentially with simple filtering and ordering. For simple cases this could be fulfilled with a Feed, and in cases where manipulation does need to be performed then a Transform off a Feed.|
|AppBoard||Stack||edgeCore||In AppBoard, provisioning and navigation were based around the Stack and a strict hierarchy of Stack → Board → Sub-Board (and so-on). In edgeCore the navigation menu a user sees is a function of what is provisioned from the Content Tree and whether the folders and pages are hidden or not. The navigation menu serves as a starting point and subsequent Switch-To-Board actions build a dynamic navigation tree (dynamically generated breadcrumbs) based on the users interaction. It is likely that the Stacks in an AppBoard deployment would roughly correspond to the top-level Content Tree Folders and Pages in edgeCore.|
|AppBoard||Board||edgeCore||Page||In AppBoard, a Board is a collection of Widgets to be presented together. In edgeCore, a Page is a collection of Visualizations to be presented together.|
|AppBoard||Widget||edgeData||Visualization||In AppBoard, a Widget represents a frame on the screen that displays data-based content. In edgeCore, this is referred to as a Visualization. This same term (Visualization) is also used for a frame of proxied web content (known in enPortal as a Channel).|
- It is recommended to use a separate system to the enPortal / AppBoard installation when going through migration. Refer to the System Requirements to ensure an appropriate system is used.
- Create a backup of the enPortal / AppBoard system.
- If possible, reduce the scope of migration work by cleaning up the existing enPortal / AppBoard system. For example:
- AppBoard: Export used Stacks which includes all referenced resources, and import this into a clean AppBoard system. This will ensure only relevant configuration remains.
- enPortal: Remove any unused targets and channels.
- For enPortal, also identify the list of PIMs installed and contact support regarding equivalent Web Adapters for edgeWeb.
- Stand up a new edgeCore installation – refer to the Migrating from enPortal / AppBoard documentation.
enPortal Specific Migration
- Install any required Web Adapters.
- Create Connections for each Target in enPortal. Initially, it may be quickest to configure static credentials with the focus on building out the content, then come back later to sort out how this will be provisioned including whether to use variable Credentials.
- Create Feeds for each Channel configured in the enPortal Provisioning → Content Management page. Note at this point this is just configuring the Feeds in edgeCore and no actual provisioning has taken place yet.
- Create Folders and Pages to build the appropriate navigation structure to match the enPortal navigation. Note: for enPortal folders using the “Tiled” layout, the equivalent in edgeCore is to create a single page in place of the tiled folder and use the layout features of a page to arrange the content.
- Edit each Page and add Visualization(s) from the desired Feed(s).
AppBoard Specific Migration
- Create Connections for each unique Data Source.
- Create Transforms for cases where Sorting, Filtering, Row Limiting is needed, or where a Relational Model is required (for Topologies, Flow Diagrams, and Treemap Diagrams).
- Create Visualizations off of the appropriate Feeds and Transformations to match the AppBoard widgets
- Create Folders and Pages to build the appropriate navigation structure to match the AppBoard Stacks and Boards.
- Edit each Page and add the desired Visualizations to match the AppBoard Boards. To arrange content to always fit the visible window, make sure the Page is in the “Dashboard” layout mode.
- Configure actions on Visualization instances. Note: the action model in edgeSuite differs quite significantly, so refer to the User Interaction table in the Feature Matrix section below.
Common Migration Tasks
- Create Domains to match those in enPortal / AppBoard. These could be for internally managed users or for externally LDAP (including Active Directory) managed users as with enPortal / AppBoard.
- Create appropriate Roles to match those in enPortal / AppBoard. This is predominantly for assigning content in edgeSuite; credentials cannot be associated with roles. In the case of LDAP-managed domains, also set up Group to Role mappings if needed.
- Assign content to Domains and/or Roles as appropriate.
- Customize the login page.
- Customize and register a custom theme.
- Create a system backup and ensure restoration on a separate clean install includes all configuration and resources. If using supported features, this should be the case.
- Validate that users with different role assignments are able to log in and have the correct content provisioned.
- Validate that Pages are showing the correct content with actions working correctly.
- If an existing regression test plan exists, it would be a good idea to run through this and adapt it to the new system. It may help cover the above validation items.
- Perform some real user testing.
edgeCore offers many new features and different ways of solving problems for customers compared to enPortal and AppBoard. While the focus of migration may be to quickly get up and running on the new platform, it is recommended to also visit some of the new capabilities in a second or subsequent pass in order to deliver even greater value to users of the system. Some recommendations:
- Explore the new Visualization capabilities such as charts with combined series types.
- Explore the new renderers offering better date, text, and icons – especially the icon composition allowing for a great deal of flexibility.
- Look at new ways to render information thanks to the item renderer used with the list, timeline, text Visualizations, and the tooltip. This allows for a configurable number of rows along with inline or floated (left/right) icons.
- edgeCore now completely supports Mobile iOS and Android devices with all Visualization types. Consider promoting this to end-users. Note that, for edgeWeb content, whether this works on a mobile device will depend on the underlying application – although thanks to the power of edgeWeb to manipulate content it may be possible to produce specific views that do work on mobile devices even if the application doesn’t support this natively.
- With the edgeData Data Pipeline, there is much greater flexibility in data manipulations which may allow for custom work previously performed outside of AppBoard to be moved into the product as supported configuration. This may also remove the need for some deployments for an external staging database.
- Also thanks to the above item, but also greater flexibility in connecting to Web APIs, it is much easier to bring data directly from applications straight into edgeCore.
Data Sources / (Data) Connection Types
|AppBoard DataSource||edgeCore Connection Type||Notes|
|Database Query (JDBC)||Database|
|Database Table (JDBC)||Database||This is not a direct replacement, Feeds must be created for each table.|
|File CSV||File System|
|File XLS||There is no equivalent in edgeCore.|
|File Shell Command||Shell Exec|
|Web CSV||Web Data|
|Web JSON||Web Data|
|Web XML XSLT||Web Data|
|Sub-Query||(Transform)||Data manipulation can be performed in the pipeline through the use of Transforms.|
|HP NNMi||An equivalent will be provided as a Data Adapter.|
|Tivoli Netcool/OMNIbus||An equivalent will be provided as a Data Adapter.|
|Service Now||An equivalent will be provided as a Data Adapter.|
Widgets / Visualizations
Unlike AppBoard, all Visualizations are supported on mobile devices. Also, installation of an app on the mobile device is not needed – simply navigate to the edgeCore URL in the mobile browser.
|AppBoard Widget||edgeCore Visualization||Notes|
|Hi-Lo / Open-Close Chart||There is no direct equivalent in edgeCore, although an alternative using multiple line and/or area series indicating the high and low may be suitable.|
|Pie Chart||Pie Chart|
|Scrolling Text||Animated Text||This is not a direct replacement as the Text Visualization is more of a single item renderer with animated transitions between items.|
|Advanced Status List||List|
|Tile Map||Icon Map|
|Google Map||Icon Map||The Map Visualization does not offer the use of Google maps.|
|Vector Heat Map||Heat Map||The Map Visualization is tile-based vs vector based so this is not an exact replacement.|
|Vector Map||Icon Map||(see above “Vector Heat Map”)|
|Region Map||This is a new Visualization available in edgeCore.|
|Diagrammer||There is no equivalent in edgeCore. If relationship information is known, or can be generated, then the Topology widget could be used instead.|
|TreeMap||TreeMap||Both TreeMap and Sunburst Diagrams are available as TreeMap Visualizations in edgeCore.|
|Web Page||There is no equivalent to embed an iframe. In AppBoard, this was the only way to incorporate enPortal content into a Board, however this is not necessary in edgeCore as edgeWeb “Visualizations” can be placed directly onto a Page. A new Visualization will also be delivered in a future release to provide the more generic capability.|
|Sankey (HTML)||Flow Diagram||Both Sankey and Chord Diagrams are available as Flow Diagram Visualizations in edgeCore.|
|Heat Map (HTML)||There is no equivalent in edgeCore. It may be possible to use a Table Visualization with either icon rules and/or background cell rules to create a similar result.|
|Small Multiples (HTML)||Small Multiples|
|Tree View (HTML)||There is no equivalent in edgeCore.|
|Quick Action||With the introduction of Page Variables and the Controls palette the typical case for Quick Action widgets should be covered. If a visual control is desired to be on a Page (as opposed to the Control palette) then a List could be used instead to set the Page Variable(s).|
|Complex Filter||There is no equivalent in edgeCore. However, it may be possible to provide the filter dimensions with a set of Page Variable(s).|
|Log Viewer||There is no equivalent in edgeCore.|
Board User Interaction / Page User Interaction
|Apply a Filter (CSF) Action||There is no client-side filtering in edgeCore; however Page Variables mapped to upstream Node Variables can be used to provide filtering operations and achieve the same end result.|
|Apply a Server Side Filter (SSF) Action||edgeCore uses a completely different model here with the use of Page Variables mapped to upstream Node Variables. When a Page Variable change occurs, mappings to upstream Node Variables are recalculated, and any datasets subscribed too on the page will get updated. Frequently, this feature in AppBoard was used to pass SHIM Query Parameters up to the Data Source Entities, and the edgeCore model makes this much easier to follow. For more generic filtering it is necessary to create an appropriate Transform node in the pipeline with Node Variables used to control the filtering conditions.|
|Bundled Actions||Not applicable, as only one action can fire at a time. In the case where multiple actions are configured in the same Visualization, an action menu is automatically shown when a user clicks an item.|
|Change Diagram Context Action||Not applicable, as nothing behaves in a way that would require this in edgeCore.|
|Clear Sort Action||There is no equivalent in edgeCore.|
|Copy to Clipboard Action||There is no equivalent in edgeCore.|
|Launch URL Action||In cases where this was used to update a URL for enPortal proxied content, then the new model for edgeCore is similar to that for datasets – through the use of Page Variables and Node Variables. For cases where a Web Widget was used to directly reference external web content, there is no equivalent for this widget in edgeCore. At the point it is introduced, it is still likely to make use of Page Variables and Node Variables to set the URL (or part-URL).|
|Refresh a Data Collection Action||Not applicable. If Page Variables mapped to upstream Node Variables change, then the datasets are automatically updated.|
|Set Widget Selection Action|
|Show Actions Menu Action||(automatic)||In the case where multiple actions are configured in the same Visualization, an action menu is automatically shown when a user clicks an item.|
|Show Data Tip Action||Tooltip|
|Show Record Details Action||Show Record Details|
|Show Widget Action||Show Visualization|
|Switch to a Board Action||Switch to Page|
|Topology Drill Down Action||Not (directly) applicable in edgeCore as the Topology Visualization does not support drill-down operations. Depending on the situation, similar functionality may be possible by the use of Page Variables mapped to upstream nodes used to drive the Topology.|
|Write Static Value Action||Server Action|
|(Widget) Text Search||(see CSF above)|
|(Widget) Download||Download Data Set|
|(Widget) Help||Help||Admin-defined help is available per Visualization, and the ability to override the help message per instance on a page.|
|(Widget) Quick Filter||This is planned for a future release. However, in some cases an alternative could be appropriate with the use of a List or Table with summary information and click actions configured to drive pageVar changes, mapped to upstream nodeVars that modify the filtering behavior of the datasets driving Visualizations on the page.|
|enPortal / AppBoard||edgeCore||Notes|
|CAC (HTTPS client certificate) User Authentication||Contact Support for assistance or to inquire about this capability.|
|SAML User Authentication||Contact Support for assistance or to inquire about this capability.|
|Custom User Authentication Request Processors||Contact Support for assistance or to inquire about this capability.|
|Password Policy||Password Policy||Configured under Provisioning interface.|
|Load Balancing||Load Balancing||Configured in custom properties file.|
|enPortal SSO methods||enPortal supports Basic Auth, NTLM (all versions), Kerberos, and Custom methods for handling single-sign-on to proxied applications. edgeWeb currently offers the same with the exception of no support for Kerberos yet, although this is planned for a future release. A major benefit to edgeCore though is that edgeData uses edgeWeb for web-data connections and doing this means edgeData can integrate with many more Web APIs compared to AppBoard, which only supported Basic auth (it did not use enPortal for SSO).|