Start reading the blog from Joy Baetty (Vice President Seilevel) titled “Gathering requirements for Migration Projects” I could only nod chapter by chapter: „The requirements gathering effort for migration projects is notably different … “ and the differences are “ … scope definition, understanding original business needs, working with end users, discovering the end-to-end functionality and IT involvement.“

That’s exactly what we figured out in over 100 migration projects in the past. More than that, most customers are experienced in maintaining and enhancing the existing software landscape, even developing new software is captured well, but a huge migration project is not the daily business for them. It requires more than you think.

All starts with the scope definition. In short terms, the first reaction is: „All the same, but better“.

In most cases, the underlying business processes won’t change in a dramatic way

PITSS 2021© Standard ratio of requirement specifications for migration projects

If we consider the amount of Function Points for supporting the various business processes in an existing application, we see such a typical distribution. The sectors treat only the business process, not the user interface, or the underlying implementation. In other words, in an average migration project you improve 17% of your business processes, create 10% totally new, get rid of 14% and correct the behaviour of 4%. More than half will remain the same as before. Once more, not from UX or technology standpoint.

Consequences for the Requirement Specification?

The Key-User is happy to describe in detail the enhancements, he’s keen to point you directly to the bugs, he beliefs to have a complete understanding of the improvements, he’s insecure about the things we could ignore and he doesn’t even have a clue, of the completeness of the things which should stay the same. With classical requirement specification you will cover in best case 31% of the business processes.

If you try to cover the rest, you rely either on existing specification in an actual version of the system – or you have to run into endless interviews with the user to understand the business needs. And you’re not sure if this fits to the actual implementation. So a second iteration of endless code reading follows.

Midsize applications could expand very fast to million lines of code, distributed over different levels of layers (Backend, Midtier, User Interface, Integration Layer, etc.) and we have to consider, that over the years of maintaining, the application is not free of technical debt, which increases the level of complexity.

How to improve 69% of the requirement specification?

Key to success is to combine the required user actions for a business process with the underlying software components. If we could associate each line of code with the order of execution to one or more business processes, we could assign the implementation, the components, more or less all of the software to the business requirements. If there is no association found, the specific part of the application could not be assigned to a business process, we could get rid of it.

How to achieve this association?

We all know the concepts of cookies on web pages, which allow us to analyze user behaviour. Usually legacy applications are not designed to deal with cookies, but with intelligent software parsers it is possible to integrate the concept of the cookies in an existing application without breaking the existing functionalities.

Cookies don’t use a high sophisticated logic, even some minor context information is necessary, to reconstruct the user behaviour. The only manifest is to insert the cookie into each procedure, user interaction object, class, etc. A perfect match for a software parser and a modern IDE.

How does this change the requirement specification?

There are two different approaches that help to get a full picture of the application in a very smooth, fast and absolutely accurate way.

On one hand the user is able to track a single but complete business process, giving a dedicated start and endpoint. The order and level of cookies describe immediately the assigned user interface, all validations, business logic and persistent functionalities. An excellent start of a retrograt business process specification. With additional annotation, the user is allowed to give feedback to existing bugs, possible improvements or any other soft facts to the process.

Do not only talk about – do it, record it, understand it. #SimplifyingComplexity

On the other hand you could observe the application from an overall perspective. Let the user run day by day through the application and let the cookies record their stories. After a while you will identify the hot spots in the application, but also white spaces with no traffic. This allows you to point the user directly to these parts of the application and ask him to record the missing business process or clarify this functionality (and by the way you could perfectly describe this through the knowledge of the missing cookies).

With the concepts of cookies in place, you could divide the implementation into five buckets

PITSS 2021© Dashboard of “DigiDocs” after a couple of recordings.

POPULAR POSTS

Modernization

Why and how to modernize legacy applications efficiently

Read more

Sponsorship project

PITSS is awarded a BMBF funding project for digital software documentation

Read more

Your Contact

Uta Daniels Assistant
of Sales Management

udaniels@pitss.com

+49 711/914-012-12

Source code analysis (or static analysis) software helps identify buggy code. Wouldn’t it be cheaper to write secure code in the first place? For a lot of enterprises, their legacy software has accrued years of technical debt, so the enterprise was unable to write secure and pristine code along the way.

One of the fastest growing areas in the software security industry is source code analysis tools, also known as static analysis tools. These tools review source code line by line to detect security vulnerabilities and provide advice on how to remediate problems they find – ideally before the code goes into production.

The entire software security market was worth about $300 million in 2007. It’s estimated that the tools portion of that market doubled from 2006 to 2007 to about $180 million. About half of that is attributable to static analysis tools, which amounted to about $91.9 million.

And no wonder; according to Gartner, Inc., close to 90% of software attacks are aimed at the application layer. If security were integrated earlier in the software development lifecycle, flaws would be uncovered earlier, reducing costs and increasing efficiency compared with removing defects later through patches or never finding them at all. Although there is no replacement for security-aware design and a methodical approach to creating more secure applications, code-scanning tools are a very useful addition to the process.

Despite the high degree of awareness, many companies are behind the curve in their use of static analysis tools, possibly due to the big process changes that these tools entail.

Key Decisions in Source Code Analysis

1 Should you start with static tools or dynamic tools or use both?

In addition to static analysis, which reviews code before it goes live, there are also dynamic analysis tools, which conduct automated scans of production Web applications to unearth vulnerabilities. In other words, dynamic tools test from the outside in, while static tools test from the inside out.

Many organizations start with dynamic testing, just to get a quick assessment of where their applications stand. In some cases, the groups that start this initiative are in security or audit compliance departments and don’t have access to source code. The natural second step is to follow up with static analyzers, enabling developers to fix the problems found by dynamic analysis tools. Some companies continue using both, because each type yields different findings.

2 Do you have the source code?

Most static analyzers scan source code, but what happens if you want to analyze third-party software or code written so long ago that you only have the executable? In that case you could try a tool that offers binary code scanning through a software as a service platform. A vendor may not be willing to give you source code, but they will give you executables or binary in many cases.

Source Code Analysis Tools: Evaluation Criteria

• Support for the programming languages you use. Some companies support mobile devices, while others concentrate on enterprise languages like Java, .Net, C, C++ and even Cobol.
• Good bug-finding performance, using a proof of concept assessment. Hint: Use an older build of code you had issues with and see how well the product catches bugs you had to find manually. Look for both thoroughness and accuracy. Fewer false positives means less manual work.
• Internal knowledge bases that provide descriptions of vulnerabilities and remediation information. Test for easy access and cross-referencing to discovered findings.
• Tight integration with your development platforms. Long-term, you’ll likely want developers to incorporate security analysis into their daily routines.
• A robust finding-suppression mechanism to prevent false positives from reoccurring once you’ve verified them as a non-issue.
• Ability to easily define additional rules so the tool can enforce internal coding policies.
• A centralized reporting component if you have a large team of developers and managers who want access to findings, trending and overview reporting.

Do’s and Don’ts of Source Code Analysis

• Don’t underestimate adoption time required. Most static analysis projects are initiated by security or compliance, not developers, who may not immediately embrace these tools.
• Do analyze pricing as different vendors have different pricing structures and your enterprise has different needs.
• Do plan to amend your processes. Tools are no replacement for strong processes that ensure application security from the beginning, starting with defining requirements, which should focus on security as much as functionality.
• Do retain the human element. While the tools will provide long lists of vulnerabilities, it takes a skilled professional to interpret and prioritize the results.
• Don’t forget the business case. You’ve got to unite the business and technical sides to ensure everyone is on the same page and that you know what to do with the results.
• Do consider using more than one tool or a tool that performs a variety of functions that will be critical to analyzing your legacy application.

POPULAR POSTS

Modernization

Why and how to modernize legacy applications efficiently

Read more

Sponsorship project

PITSS is awarded a BMBF funding project for digital software documentation

Read more

Your Contact

Uta Daniels Assistant
of Sales Management

udaniels@pitss.com

+49 711/914-012-12

Since Reports will not be part of future Forms releases, customers are left with the question of what to do. Oracle intends to push Forms customers towards the use of BI Publisher, which is Oracle’s preferred replacement for Reports. Therefore Forms 12c has been delivered with an much easier integration of the BI Publisher Reporting solution.

But are there any other alternatives out for Oracle Forms customers? In this blog, as part of our Oracle Reports series, we give an overview of the some of the most popular solutions when it comes to Oracle Reports alternatives.

The Last Reports Release

As early as October 2016, Oracle announced that Oracle Fusion Middleware 12.2.1.3.0 was the last report release. In addition, they revealed that Oracle Reports support would fully retire in 2023. Enterprise applications based on the Oracle Fusion middleware stack, which includes Oracle Forms and Reports, are therefore faced with a big problem. They need to immediately plan their new reporting strategy. But what Reports alternatives are currently on the market and what are their benefits?

POPULAR POSTS

Modernization

Why and how to modernize legacy applications efficiently

Read more

Sponsorship project

PITSS is awarded a BMBF funding project for digital software documentation

Read more

JasperReports

Why should you consider Jasper Reports as a serious Oracle Reports alternative?

Well there are quite a few good reasons, but the main one: JasperReports is open source – well at least to a certain degree. JasperReports is developed and maintained by Jaspersoft. You can create your JasperReports using the main library and distribute them as long as you don’t change the source code. If you need further support from JasperSoft or different licensing, then you have to buy additional products.

The second main reason for Jasper is, that it is written in Java, which is widely used. JasperReports can handle various data source options: JDBC, Hibernate, XML, EJB, POJO. While there are many data sources possible, there are loads of export formats available: PDF, HTML, XLS, RTF, ODT, XML, CSV, TXT, DOCX.

JasperReports from TIBCO is probably the Java based open source solution with the widest community. Similar to BIRT, reports development takes place in the Eclipse IDE and at runtime, the engine can be integrated into any Java application. In contrast to BIRT, Jasper can also be consumed via a scheduler or web services. That Oracle Forms integration very flexible and diverse.

Strengths

• Broad coverage of various data sources
• Pixel-perfect issues possible
• Very performant for long reports

Weaknesses

• Cumbersome subreports for multiple data sources in a report
• Pixel-perfect issues possible
• Few out-of-the-box aggregate features

Commitment, Problems, and Solutions

The possibility of integrating JasperReports via WebServices and URL calls also makes the tool interesting outside of pure Java application development. Pixel-perfect printing also allows safe use for classic tasks such as labels, barcodes and forms. If it is the first step in the Java world, the learning curve should not be underestimated like in BIRT.

While using Jasper Reports has some benefits it comes with some negative aspects and problems when you are moving from Oracle Reports. The biggest problem for most Oracle Reports developers will be the fact, that Jasper is not supporting PL/SQL. So if there is a lot of logic or validation in your reports we recommend to move the PL/SQL Code to the database and refactor the validation within Java.

Another problem could be, that you need Java knowledge to utilize JasperReports: If you already have Java knowledge in your company your Java developers will find it easier to work with JasperReports, but if your developers are pure PL/SQL developers Java training to a certain extend is not a bad idea. Also Java resources are quite common (Java is still the most famous programming language).

No PL/SQL support	move PL/SQL to DB/Java
No validation triggers	refactor logic with Java
Generally limited triggers	refactoring, sub-reports
No detailed filtering of query groups	refactoring
No PL/SQL formula columns	refactoring
Too many sub-reports can result in very poor performance because each sub-report opens its own database connection, thread and query	perfomance test + refactoring, if necessary

Oracle BI Publisher

Oracle’s official successor and recommendation for reporting is the Oracle BI Publisher. If asked, then Oracle would say there is only one real Oracle Reports alternative: Oracle BI Publisher. But BI Publisher (in the past XMLPublisher) is not a one-to-one replacement for Reports; it’s rather another option for reporting that is quite different from Reports.

BI Publisher divides the reporting into data, layout and language.

This changes the flow of work when it comes to the creation of a report. The advantage is, that reports that use the same data source but have a different layout must not be created multiple times. For creating these different layout-templates the development environment or a Microsoft Word Add-in can be utilized. An additional advantage of BI Publisher compared to Reports is that BI Publisher supports many sources and export formats.

One is not limited to an Oracle Database as a source of data – you can use different other sources like WebServices, files or external systems. Those can be exported to a wide range of formats like: PDF, PPT, SML, Excel to different output channels (printer, filesystem, mail etc.). BI Publisher additionally offers a dashboard functionality with which users can create their own reports. All of those mentioned possibilities make BI Publisher to a not to cheap Enterprise Reporting solution.

If you have licensed the iAS-EE the use of BI Publisher is free of an extra charge.He also supplanted Oracle Reports in Oracle’s own ERP suite. The strict separation between layout and data collection goes two steps further and makes it possible for the end user to create, manage and consume their own reports very intuitively via an online-builder and also to make this separation with standard XML technologies an efficient one Multilingualism of the reports. The BI Publisher is available through the metrics Named-User-Plus (395 €) or Processor (39,500 €).

Strengths

• High degree of modularization (sub-templates, reuse)
• Self-service portal for central reporting solution
• Bursting and online dashboard
• May be covered by Oracle Forms license

Weaknesses

• Requires know-how from XSL-FO
• Pixel perfect printing only cumbersome
• Requires BI Publisher Server within the Weblogic servert

Commitment

If the Forms and Reports application is licensed on the basis of an Oracle Application Enterprise Edition, the BI Publisher is the natural successor. The integration with Forms is predefined by Oracle and the integration into other applications based on APEX, ADF or other Java frameworks is very easy. The range of functions certainly surpasses all other alternative solutions.

Eclipse BIRT

BIRT is an open source solution from the Eclipse Foundation for the preparation, visualization and reporting of data within rich client or web applications based on Java. Report design and implementation takes place within the Eclipse IDE and a BIRT Report Designer. Then, applications integrate via the Report Engine, which can be integrated into any Java application with a Java API.

Strengths

• Broad coverage of various data sources
• Great variety of different output formats
• Powerful charting engine

Weaknesses

• Graphic elements are missing
• Pixel perfect printing only cumbersome
• Page-related values (subtotals, page numbers) are only cumbersome

Commitment

In a holistic Java-oriented application development, BIRT certainly finds its rightful place. The existing BIRT Report Viewer can be used as an independent application and enriches the functionality of your application out of the box.

APEX Office Print

In the field of application development with Oracle APEX, the Belgian company APEX R & D has developed the product APEX Office Print (AOP). Data from the Oracle database or usable web services are linked to Office templates (Word, Excel, Powerpoint) and can be output in PDF or Office formats. Additional functionalities include integrated mailing functionality, various barcodes and the ability to generate interactive reports. The licensing model distinguishes between the cloud solution on a rental basis and the on-prem installation.

Strengths

• Flexible through various APIs
• Simple template creation via Office Tools
• Easy to integrate in the apex environment

Weaknesses

• Complicated creation of pixel-perfect printing
• Requires Apex version 4.2 or higher in the database
• Business logic from PL / SQL is difficult to adopt

Commitment

If your Forms applications future plans are to migrate to APEX, the APEX Office Print reports are almost perfect. The lightweight installation (based on APEX) offers a clear added value with interactive reports.

PL/ PDF

PL / PDF is a reporting tool of the Hungarian Oracle partner OraNext, which can only create documents as PDF, DOCX or XLSX with PL / SQL resources in the Oracle database. As a layout designer, a Word or Excel template can be used. The licensing allows a model by output format or per server.

Strengths

• Performant for large data retrieval – runs directly in the database
• Based solely on PL / SQL
• Small footprint, can be easily integrated into the application

Weaknesses

• Does not support other output formats
• Linked to a database and thus not usable as enterprise service for other applications
• Limited functionality (no BI, no self-service, no multilanguage support out of the box, etc.)

Commitment

PL / PDF is ideal if a manageable number of well-defined reports has to be created in the tightly-knit environment of the application. The integration is easy and easy to use for PL / SQL savvy developers.

Which target technology do other report users choose?

The answer to the question of where most of the market will go is usually its reasons. That’s why in our September 2016 webinar “The End of Oracle Reports” we asked more than 100 attendees about the technology they plan to use to replace Oracle Reports.

Remarkably, as many as 79% of participants were still unsure or undecided about the technology choice. Due to the importance of the decision, however, it is understandable and sensible on the other side that a final decision is not “broken over the knee”.

Among those who made their decision, Jasper Reports is the clear favorite, followed by Oracle BI Publisher and PL / PDF. However, few webinar participants considered BIRT, APEX Office Print, or a completely different tool for the best possible solution, but this does not have to be an exclusion criterion. As mentioned earlier, almost every technology has its raison d’être, if it suits the individual needs of the company.

Migration Issues

After deciding on a solution, you should also consider how a migration from Oracle Reports to the target technology will look. What all of these Oracle Reports alternatives have in common is the fact that there are different ways to approach the migration process.
Data model: In general, migrating your reports does not change the underlying data model. Often, however, migration is taken as an opportunity to clean up technical debt and reporting processes. Consolidate double queries, validate calculations, and add a future-proof report layer, which also provides valuable data for other BI solutions.
Layout: Reports has created a definition that can not be arbitrarily transferred to other tools with its design of the layout via coordinates of the elements and repeating frames (which can also be nested arbitrarily). A rough approach succeeds in every migration, but the biggest effort is surely to get everything back to its right place. Especially the tools that do not support natively pixel perfect printing prove to be a bigger hurdle.

Conclusion

Oracle Forms customers are currently under some pressure regarding the use of Oracle Reports. Since the last Forms Release 12.2.1.3.0, it has been confirmed that Oracle Reports will no longer be supported by 2023 at the latest. This creates the need to look for a suitable alternative in the market. In this paper, you were presented with five different solution alternatives, each with its own advantages and disadvantages. The decision depends on many factors within your application as well as the environment within which this application is developed, maintained and used. We will gladly show you which alternative is best for you in a more detailed analysis.

Your Contact

Uta Daniels Assistant
of Sales Management

udaniels@pitss.com

+49 711/914-012-12