Defining Your Upgrade and Cloud Strategies: A New Path to Oracle WebCenter Portal

Path Blog Banner

Defining Your Upgrade and Cloud Strategies: A New Path to Oracle WebCenter Portal

By: Kevin Donnelly | Director of WebCenter Portal Consulting

It’s never as easy as the marketing says. Often, a Portal application has so many dependencies that you find yourself stuck in the ground rather than moving up to where you want to be. Priorities lie elsewhere, and you end up with a portal which is up against – or past – end of life, running on old hardware on the verge of being completely unsupported, with no guidance or path laid out on how to successfully move onto a modern platform.

Portal applications are particularly prone to getting caught up in an end-of-life cycle. Typically, a business’s intranet/extranet Portal application serves as a clearinghouse and an aggregation point for a wide variety of different functions – both directly through the Portal, and indirectly through integrations to the backend. This tends to result in the perceived value of upgrades and additional functionality being higher for those endpoints being exposed through the Portal than to the Portal itself; and with any major piece of software, it can fall behind the curve for support. Once that happens, it’s a slippery slope to falling multiple versions behind, paying more for support (or losing support altogether), and turning into a complete legacy portal implementation that no-one wants to touch for fear of breaking the whole implementation.

Unfortunately, crossing your fingers and hoping nothing goes wrong has never been a good IT plan.

If you are in the situation of having a legacy, currently (or soon to be) unsupported Portal implementation, you need to actively consider your path to a more modern, supported, stable platform – both software and hardware. Below are some initial questions typically asked when helping enterprises build their transition path to a more stable Portal implementation.

Infrastructure Approach: On-Premise, Off-Site, Cloud, or Hybrid models?

One driving force behind changes and migrations of legacy software (Portal or not) has always been underlying hardware changes. It’s no coincidence that changes to the support of underlying server software aligned with a number of legacy software migrations. This was seen when Microsoft’s Support for Windows Server 2008 ran out, and it appears to be ramping up again as Oracle’s Solaris 10 leaves Premier Support in less than 9 months. Other considerations are hardware life – owning a physical server means that there will be times when purchasing new servers are necessary – and the simple support appetite for continuing to hardware in-house. More and more companies are looking at a Cloud infrastructure to host their software needs, but question if it’s a good overall fit.

When working with someone to help build that transition path, we find the best by using a solid justification based in true cost and functionality. This includes not just the immediate costs of migration to a new platform, but the ongoing cost of the infrastructure, support of the platform, software licensing (which often differs between on-premise, virtual, and Cloud environments!), and future hardware/software purchases or renewals.

From a functionality perspective, it is important to look at all of your options to be sure you are choosing what best fits your needs. First, choose a category – choose Cloud when you want to get out of the business of owning hardware, and Hybrid when there are applications which can’t move off-premise, etc. What the Oracle Cloud offers is different than what you will get at AWS or Azure; and even within any of these there are significant different options which will result in very different certifications, costs, and maintenance/administrative controls and experiences.

Portal Application Support Approach: Lift and Shift, Migrate, or Rebuild?

As with infrastructure decisions, a good application roadmap requires due diligence and strong planning. One of the characteristics of Portal implementations is that no two are exactly alike – because no two are serving quite the same audience, or have exactly the same needs. That being said, many of the same underlying questions and scenarios continually repeat themselves. There is a tendency to think that since your particular implementation is unique, that the problems you face are unique as well – and that is rarely the case. The first step to planning the future of your existing Portal implementation is taking a good look at not just the current implementation, but your current needs – how have your business needs changed since this was put in place? What new business problems or challenges may have come up? What functionality may no longer exist in a new version or product that would still need to be handled? Is there an absolute need to stay on a particular release due to compatibility issues in the short or long term; and how can that balance with other requirements?

Once the end stage is determined, a good roadmap will be sure to cover the entirety of the path to get your Portal implementation where it needs to be. Environment planning (Dev / Test / Staging, etc.) can give you a path to get a toe in the water of a new infrastructure; but those needs often change drastically in a Cloud or Hybrid environment. Are you planning with the support needs of the current Portal in mind? Are you fully mapping your functionality and your content? The plan also needs to consider the quirks of the legacy system – what customizations and integrations can be reused? How can you migrate the legacy content into a new system?

In the table below, there are a number of common legacy Oracle-based Portal implementations that we’ve worked with, built roadmaps for, and performed migrations on – whether lift-and-shift to a Cloud or Off-Premise environment, or as a fully new Portal implementation. Each of these has some similarities of approach, but also their own challenges to overcome, regardless of the destination.

Portal SoftwareCurrent VersionSupport StatusCommon Implementation Characteristics
WebCenter Portal Server WebCenter Spaces11. (August 2015)Premier Support (ends Dec 2018)• Content and Document Management done via integration with WebCenter Content • Search provided by Secure Enterprise Search or via WebCenter Live Search • Integrations to other Fusion Middleware Platforms • Custom Applications provided via ADF Task Flows • Customized User Interface via Skins and Templates • “Deep” extension of out-of-box tooling typically via replacement rather than extension
WebCenter Portal Framework11. (August 2015)Premier Support (ends Dec 2018)• Content and Document Management done via integration with WebCenter Content • Applications typically included many custom ADF Task Flows • Functionality typically implemented via custom code • Pages were often built within the application and deployed rather than via web tooling
WebLogic Portal10.3.7 February 2016Premier Support (ends Dec 2018)• Most functionality implemented through custom integration and development • Application functionality typically the primary focus of the Portal • Java-based development; typically very customized with complex portlets/applications
Oracle Portal (11g/10i) December 2011 10.1.4 September 2005Sustaining Support (Indefinite)• Heavy custom development, including the PDK and JSR and standards-compliant portlets • Often PL/SQL applications are integrated through out-of-the-box portlets • Generally tight integrations with other Oracle backends
WebCenter Interaction10.3.3 December 2011Sustaining Support (Indefinite)• Integrates to a variety of backends, including custom web applications (Java, .NET and other) • Identity integration typically to an Active Directory or LDAP environment, although users are often managed directly through the Portal • Typically a long-standing portal implementation, exposing diverse applications to its user base • Search indexing in the 10.3.3 version will need regular rebuilds and is often an issue
AquaLogic Interaction6.5 MP1 June 2008End of Life• ALI 6.5 is fully out of support, so typically companies will have either good internal knowledge of the system, or it has remained stable for some time. • Integrates to a variety of backends, including custom web applications (Java, .NET and other) • Identity integration typically to an Active Directory or LDAP environment, although users are often managed directly through the Portal • Typically a long-standing portal implementation, exposing diverse applications to its user base

If you are running on any of these platforms and are looking to move to a modern platform and/or a Cloud-based implementation; feel free to reach out to TekStream Solutions for a conversation, or check out the TekTalk webinar replay: Upgrading WebCenter Portal to the Cloud.  We’d be happy to talk to you about your plans for Portal migration, and how to best put you on the path to success.

[pardot-form id=”13937″ title=”Blog-KevinDonnelly-Path”]

Hey Inspyrus AP Automation! Can My JDE Come Out To Play?

Inspyrus JDE Integration

Hey Inspyrus AP Automation! Can My JDE Come Out To Play?

By: Marvin Martinez | Senior Developer

So you’re interested in AP Invoice Automation but have found that there is not much support for your JDE ERP amongst the automation crowd? Fortunately, Inspyrus Invoice Automation plays well with various ERPs, one of which is JDE, allowing for full integration with this ERP.

Inspyrus Invoice Automation is fully compatible with various ERPs, including EBS, PeopleSoft, and JDE. The integration is seamless from the user’s perspective as the Inspyrus Invoice Automation Solution will execute this integration behind the scenes, relaying business validation errors and messages to the user and automatically importing invoices into the ERP of your choice. This has the added benefit of allowing users with various ERP skillsets to work with a unified user interface that is ERP-agnostic. Note, in the image below, that the ERP being integrated has no real bearing on the user interface and shields the user from the burden of dealing with the ERP directly. All of the functionality is provided via the user interface which streamlines and facilitates many ERP actions.


Once the solution is configured, PO matching, invoice processing, and approval routing all work similarly, regardless of what ERP the solution is integrated with. One may ask, however, “how is this all done?” Aren’t EBS, for example, and JDE distinctly different ERPs? They are distinctly different but, as a robust invoice automation tool, Inspyrus Invoice Automation can be configured quickly to work with any of these ERP systems with a few streamlined configuration steps.

First, the Inspyrus invoice validation procedures are quickly configured to work with the JDE BSSV (Business Service) web services, up to and including JDE 9.2. These services are used by the Inspyrus solution to validate invoices according to the validations and rules defined by the JDE instance. Any errors returned by these BSSVs will be displayed in the Inspyrus solution so that they may be corrected before processing can complete.

Second, the Inspyrus solution is configured to use the database of the JDE instance. This configuration is streamlined and implemented by default with the most common scenarios for retrieving vendor, purchase order, tolerance, and additional data. You might ask, “What if our JDE instance does not fit these common scenarios?” Rest assured! The solution is easily configurable to retrieve the data in accordance with a specific JDE instance’s configuration. All of the above information can be rapidly and efficiently configured to retrieve relevant business data from wherever it exists in the JDE instance. Have specific codes in a different place to distinguish a 3-way PO from a 2-way PO? No problem! Inspyrus has you covered.

Finally, and potentially most importantly, the Inspyrus solution, now communicating with the JDE instance’s database, can be easily configured to leverage the existing approval hierarchies configured in JDE. This integration allows for real-time changes to the approval hierarchy to be reflected in the Inspyrus solution. Approvals within the Inspyrus user interface are streamlined (even allowing for email approvals) and tracked for easier reporting, along with a multitude of other metrics.

The Inspyrus Invoice Automation solution is extremely versatile on many fronts. One of these fronts is ERP integration. The fruits of the AP Invoice Automation tree should not be restricted to certain ERPs. The Inspyrus Invoice Automation solution is fully positioned to not only make, but keep true, to that claim. JDE customers, your AP Invoice Automation solution is calling! Contact us for more information on automating your invoice processing!

[pardot-form id=”13913″ title=”blog-marvinmartinez-JDEInspyrus”]