Introduction
In modern application development it is propagated to use webservices and even use certain tools like the Oracle SOA Suite or Oracle Service Bus to manage and orchestrate webservices in a central environment or to enable service abstraction. But many Oracle Forms developers find it hard to use these methods in their application and other applications to reuse the existing business logic by deploying a webservice. But since there is a significant raise in mobile enablement, also legacy systems like Oracle Forms applications should benefit from generating webservices.
“Application infrastructure and middleware
projects are becoming the cornerstone of the
digital business.”
Fabrizio Biscotti
Gartner Research, 2014
The main problem that Oracle Forms developers face when you ask them to implement SOA into their applications or build webservices based on logic on source code from Forms, is the fact that SOA is a paradigm – it’s not a technology or a product – it is a concept. And it is different from the concepts on which legacy systems base on.
Also do Oracle Forms applications tend to be monoliths, where it is hard and time consuming to identify the business logic and move this logic to the database and build a webservice on top. A second problem is often to first identify code, that really is a key process in a application, meaning which is used heavily and for which it would make sense to build a webservice.
The Oracle SOA Suite and especially the Service Bus enables Developers to publish, manage & orchestrate webservices. Keywords here are mobile & cloud enablement – but also it is easier to switch technlogies when using webservices, especially in the SOA Suite. Oracle Forms is able to consume webservices. So if we have a way to record the business logic that is used much often in our Oracle Forms application, convert it to a webservice and deploy it on the Service Bus we would be able to consume this logic in other technologies. This is where PITSS.CON comes into play. With the use of a database repository, where it is possible to load the whole Forms Application into, analyze it and record certain processes into a backlog called user stories, PITSS.CON is able to transform logic from Forms into the database and make it accessible for the Oracle SOA Suite. So those two products harmonise very well together.
In this article I would like to show you, how to do so. As a example I took “orders.fmb” demo. You can see the runtime screen above. Basically this form displays orders and the corresponding customers when clicking on “customer information”. I would like to extract this logic from the fmb.
Recording of User Stories
As part of the solution PITSS.CON was used to identify the business logic by injecting an 
Oracle Forms application with a logging mechanism called “user stories”. But before that we did several steps within the tool to get rid of the unused & redundant code – because we don’t want to generate a webservice for code that is not in use anymore or redundant. While PITSS.CON is a repository based application, it is possible to easily identify redundant code through the comparison of program units. Dead code can be found when searching for program-units that are not called by any Trigger. After we have done that, it is much easier to concentrate on the “used code”. But how is it possible to identify code, that is used in applications and central to them? PLSQL-injection is the keyword here. With PITSS.CON we can easily inject all triggers and program-units of an application.
The injection is basically a logging mechanism which writes the callings in a application into a logging table. Afterwards this log table is evaluated by PITSS.CON. So we get a connection between the development tool PITSS.CON
and the processes that the application users utilise the most in the application. We enable the users to record their daily work processes.
Business Logic to database
With these information we are able to manipulate the application. So we have the whole application loaded into the repository and we know exactly which objects are used – so we create this process as a subset of our application and move the logic to where we want – either another technology or the database. In this example
we moved the logic to the database. This can be done with the PITSS.CON module “Business Logic to DB”. Here it’s possible to select a program-unit or trigger and calculate the dependencies that occur, when moving an object to the database. Also a complete flow can be moved. PITSS.CON gives certain information on how easy it is to move the process to the database. If In our case we want to transfer a whole flow to the database – we check the metrics and click on “transfer objects to DB”. 
We will then be asked in which package we would like to add the procedures and PITSS.CON will automatically build a package with the given procedures – also it will insert the necessary parameters from form variables or objects so that the procedures will work correctly. After this step we will get the following source code, so that we can create the package on the application database.
Create SOA Application
Now we can build a webservice on top of this package. For that I used the ability of the Oracle SOA Suite and built a Webservice based on the newly created db-package with an adapter. An db-adapter in the SOA Suite is a basically a webservice, which is wizard based and gives us an easy access to the database package. On the picture below, you can see the outcome of the new created db-adapter on the right side: getCustomerID is a SOA Suite adapter, which is based on the database package that was created earlier with PITSS.CON.
I just added a mediator component to create a value mapping and the SOA Suite created a webservice (SOAPService) which can be consumed by another technology. Here the Oracle Mobile Application Framework (MAF) was used to use the webservice from the SOA Suite. After that, the SOA application was deployed on a Oracle Weblogic Server.
Consume webservice in MAF
So basically the process of getting Customer information was recorded with PITSS.CON from the good old Forms module “Orders.fmb”, moved to the database and a webservice adapter was created via the SOA Suite. With the help of a Mediator component we achieved a value mapping and finally we’ve built a mobile application on top of the SOA application. So here is our simple mobile application, which gives us customer information on our mobile device:
So now we got the logic in the database. Whenever we want to change something on the logic we just have to change the db-package. We could also implement the webservice into our Forms application. But that is a topic for another blog article.
