06.05.2024 Stuttgart/Troy – The new Forms2APEX Modeler 24.1.1 is available and it is one thing above all – even more efficient than its predecessor. It has succeeded in automating even more tasks in an Oracle Forms to APEX modernization project. This increase in efficiency and further improvements to the software are the result of current modernization projects in which the Forms2APEX Modeler has already impressed customers and project teams with enormous time savings and high-quality results.

A central aspect of a successful Forms to APEX modernization is the transfer of valuable software artifacts (PL/SQL code) from Oracle Forms to the database in order to make the code available for the new APEX application. In the new version of the Forms2APEX Modeler, there are more options for transferring PL/SQL code to the database. This means that significantly more objects (e.g. PRE and POST-QUERY triggers) can now be transferred and at the same time adapted to individual requirements. This means that code can be added automatically if required (e.g. for additional logging and additional error handling), but the complete structure of the database packages (user interface driven or table API based) can also be decided. This safeguards investments in existing validations, transaction logic and implemented business processes.

The interactive, visual representation of the Oracle Forms structure also makes it easy for developers who do not have in-depth knowledge of Oracle Forms to familiarize themselves with the existing sources within a modernization.

Depending on the selection of the APEX region to be created and the field and record validations found in Oracle Forms, validations, dynamic actions and alerts are automatically generated in APEX. In Oracle Forms applications, the validation triggers are the most frequently used triggers alongside the command areas, which means that this generation can save a great deal of time and ensure that validations are not “forgotten” or incorrectly applied.

When transferring Oracle Forms blocks to APEX regions, the new Forms2APEX Modeler release gives developers more options for the master-detail use of regions. For example, the new Modeler helps with the selection of regions with context-related information.

In release 24.1.1 of the Forms2APEX Modeler, a completely new and revised checklist has been developed for the remaining work after importing the generated sources. The dashboard shows project managers the status of the current modernization project at a glance, including the next modules to be completed, the current activities of the developers and the progress of the migrated modules. For the developers, the checklist is a safe and convenient tool to ensure that nothing is overlooked in the remaining work. The context-sensitive display of objects, properties and code makes the use of the Forms Builders almost superfluous.

Please feel free to make an appointment with us:

Your Contact

Uta Daniels
Assistant of Sales Management

udaniels@pitss.com

+49 711/914-012-12

Review of the webinar “Top
challenges in an Oracle Forms
to APEX modernization”

The overwhelming response, with over 180 registrations, underlines the significant interest in this crucial topic. A special thanks goes to Mónica Godoy, Senior Principal Product Manager APEX at Oracle, who enriched the discussion enormously with her great knowledge.

Stuttgart 03/25/2024 – On March 13, 2024, the modernization expert PITSS hosted the live webinar “Top challenges in an Oracle Forms to APEX modernization”. Developers, Programmers, System Architects, Project and IT Managers from all over the world were invited.

In the webinar, the experts provided answers to the most frequently asked questions about Forms to APEX projects in a panel discussion. The most important questions were collected before and during the webinar. The audience took the opportunity to ask their questions. From technology decisions and project planning to the transformation and possibilities of the new APEX application, everything got covered.

An important point of discussion for all Project Managers was Business Logic to Database and its immense importance within a modernization as well as best practices from real world modernization projects.

The numerous advantages of modernization according to Oracle APEX presented by the panel were then able to motivate even the last doubters to face the topic with enthusiasm and confidence. After all, modernization, redesign, simplification, more functionalities and possibilities, no limitations for mobile devices and less complexity in the application are just some of the weighty arguments for the transformation to APEX.

If you want to watch the entire webinar you can request the recording here.

Outdated legacy applications are the greatest threats to companies’ productivity and revenue. The traditional incremental approach to migrating and modernizing legacy applications is costly and inefficient and often taking years. With PITSS, it’s completely different.

As leaders in digital transformation, we migrate and modernize business-critical legacy systems in a fraction of the time it takes to do so manually.

What sets us apart are our PITSS Products in particular our Application Data Cube (ADC). The Application Data Cube analyzes software without overlooking a single line of code within the shortest time. It allows you to identify and isolate obsolete UIs, business logic, and databases then replace them with updated constructs.

Get inspired by the importance and simplicity of software modernization in 90 seconds.

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

f.l.t.r.: Andreas Gaede (CEO PITSS), Edher Diaz (PITSS), Prof. Manfred Reichert (Head of Institute Databases and Information Systems (DBIS), University Ulm), Stephan La Rocca (PITSS), Lisa Arnold, Marius Breitmayer (both University Ulm).

Stuttgart 02/28/2024 – On February 22, 2024, PITSS, one of the leading modernization experts for Oracle applications, hosted a meeting of the project partners of ProcMAPE (Data-driven adaptations of process-oriented software systems through monitoring, analysis, planning and implementation). Professor Manfred Reichert from the Institute for Databases and Information Systems (DBIS) at the University of Ulm and two of his team members discussed the BMBF-funded project in detail with the PITSS experts.

The innovative ProcMAPE project, funded by the Ministry of Education and Research (BMBF), involves the development of a MAPE (Monitor, Analyze, Plan and Execute) framework for the data-driven adaptation of object-centric processes in software systems. Prof. Manfred Reichert and his two research assistants Lisa Arnold and Marius Breitmayer, as well as PITSS project manager Stephan La Rocca and his colleague Edher Diaz, were involved in the exchange on the project.

The aim of the “ProcMAPE” project is to enable (partially) autonomous, data-driven adaptations of object-centered processes in software systems.

The expert panel discussed the current project status, further project requirements and ideas for achieving the objectives and the possibility of working with LLM and AI in future projects. Project manager Stephan La Rocca was very satisfied with the project status: “We are already recording all interactions with a system for monitoring, from the user interface to the database transaction. In the next step, we will focus on the possibilities of AI for analyzing the recorded events.” All project participants agreed on the importance of personal exchange, even in such highly innovative projects.

Further information on the ProcMAPE project:

Stephan La Rocca
ProcMAPE Projektleiter
E-Mail: slarocca@pitss.com

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

Individual consulting for the

modernization of your software

Ask without obligation

Your Contact

Uta Daniels
Assistant of Sales Management

udaniels@pitss.com

+49 711/914-012-12

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