Previous Job
Previous
OpenText WEM/Portal Consultant - Contract
Ref No.: 18-00532
Location: Poughkeepsie, New York

Our client is currently seeking a OpenText WEM/Portal (version 16) Consultant to work in their Poughkipsee, NY location.  Don't miss out, apply today!!! 
 

Architecture and Stability of Current Environments:

  • Current architecture relies on a single point of failure - apache reverse proxy shared for dev/test/prod
  • Reverse proxy also rewrites almost every URL passing through it, affecting page load times due to apache overhead and causes unnecessary noise in all logs.
  • Designed dataflow requires a user, depending on whether authentication is needed or not, to bounce back and forth (.NET Application Server, redirect to the reverse proxy, internal OpenAM server, back to (.NET Application Server, then connect to the frontend WEM server, then connect to the backend WEM application server).
  • Performance issues with CHGE web site during large storm event. When attempting to make modifications to try to alleviate performance issues, unable to completely change main landing page. While experiencing system issues with WEM Preview, inability to make changes to the CHGE website. Under normal conditions the inability to manage our website content is not acceptable. Even more of a concern is, in the event of a sudden public emergency, there is no alternate option to update the website outside of WEM.

OpenText WEM Issues:

  • WEM Workspace - Error messaging is generic so you are not sure how to resolve even the simplest of errors. Ex: backing out changes. If you do not back-out in the order originally stepped through, a generic server error message will display.
  • Current Dev/Test UAT/Prod environments are not synced. Dev and Test do not always match Production.
  • Lack of migration processes across environments, Dev a` Test UAT a` Prod. Content has to be added directly to Prod. Also current methodologies do not provide any true content versioning in the product.
  • There is no workflow established for creating and publishing content.
  • Issues promoting code from Test UAT.
  • Lack of clarity on what needs to be "published” in order to get a change live on the site.
  • Content items do not always publish (this affects retargeting scripts).
  • Publishing content sometimes takes up to a day due to a backlog in the que. (this should be virtually instant)
  • Issues creating MyAccount marketing teasers when implementing personalization leveraging OpenText Segmentation & Targeting features.
  • Developers have limited, to no access of some Consoles because the Consoles require Administrative rights.
  • Lack of ability to stand up local Sandbox environments for each developer to develop and view changes.
  • Matching security roles/permission assignments across the environment do not provide the same results. Ex. Developers were setup with the same permissions, however some do not have the capability to publish in Test UAT.
  • Interface can freeze while editing items within frames of a page.
  • Templates seem to limit the capabilities of incorporating widgets.
  • Internal server errors randomly returned to content managers on portal pages. Sometimes items cannot be added or deleted and will get a generic "Internal Server Error” message with no error logging.
  • We discovered a configuration issue where, in an html page, a setting required the exact same number of characters to be entered as the previous value, not matching this requirement put the entire site into a stale state and would only load a blank page.
  • Documentation:
  • Customized code is not commented/documented. Without comments or documentation to customizations, some aspects are not known.
  • Documentation - no internal best practices documents exist for the product.
  • Workflow processes (content approval) are undocumented.
  • Vanity URLs do not always work correctly.
  • File name duplication - believed to be a remnant of the initial migration to WEM. Files are named the same but with different modification dates. Not always clear which file the workspace is referring to, causing confusion and rework on some occasions.
  • The WEM folder structure is not intuitive. (Causing multiple instances of identical content pages)
  • Lack of flexibility and access to edit the full page code. Difficulty to manage the website through this system makes it really discouraging to do anything beyond the most basic, required changes. Sometimes requires significant trial and error to figure out how to make a change, if a particular change is possible, and if a change will work properly within the system. (Ex. Replace a jpg with a video. Template does not allow this.)
  • Restricted access to modify page code.
  • No split-screen Code/WYSIWYG edit mode.
  • Clicking the "Link to Page” button in the WYSIWYG editor causes you to lose all unsaved work and requires you to close out of all windows and log out of the system and log back in, or clear browser cache to fully access WEM again.
  • File structure and the process required to execute many tasks is not intuitive.
  • The search functionality is not good. You often have to know the exact name of the file you're searching for.
  • The "Channel Association” requirements can be difficult. Lack of clarity on the need for this. Only one individual has access to post content on the web server associated to the "Unassigned Content” channel (set up for hosting images used in email blast, eBill notification mailings, and FERC Open Access documents pages).
  • Inability to publish Headers and Footers in such a way that they can be utilized across platforms, both internal sites and external sites. Currently when changes are made to Headers and Footers, they must be manually updated on third party sites.

General Issues:

  • Customer Experience - feedback with logging in indicates sporadic system issues that do not seem to be related to user error. It is unclear exactly what/where the issues are. Web Help Desk tickets can be provided for sampling of these types of issues.
  • OpenText WEM/Portal implementation is overly complex. Overall difficulty of navigating the WEM system to make changes. It is often difficult to find where a piece of JavaScript is coming from. This may be related to our implementation and customizations in order to migrate content and utilize existing ASPX applications. Clarification on whether current design can be better streamlined without a complete rewrite, or whether a rewrite is necessary