To write business logic in a nvo that can be migrated to a Web API means you have to design the nvo with a service architecture mindset first and foremost. You need to think of it as an object which will perform specific functions through its methods and from which you cannot know anything about its state afterwards.

For example, I may have a function that takes a customer’s order and creates multiple vendors orders based on a recipe. A customer orders a cake, so I need to buy flour, sugar, milk, eggs, etc. So, I’ll create a method within a nvo that will receive an order number, read its products detail from the database, check the recipe, insert vendors orders in the database, and return a successful/fail response. This can then be easily migrated to a Web API.

Most of the examples you’ll see in the Appeon Community Webinars don’t cover this scenario. Those are aimed at explaining how to migrate your database access to a Web API instead of directly connecting to a database, which is really useful if you want to cloudify your existing applications, but that does not necessarily means business logic migration.

In those examples the database logic contained in the Update method of the DataWindow (proprietary of SAP/Appeon) is transported to a new object called .NET DataStore which has the same method and can perform the same function but in a remote database. So, the Web API just acts as a transfer mechanism of the data and metadata needed to perform the update (insert, modify, or delete). I see this as a database logic migration rather than a business logic migration. Nevertheless, it is a very powerful feature for us PowerBuilder developers.

In the end it all depends on what you want to do. In PowerBuilder 2019 R2 Appeon has provided us with the tools needed to do both, database logic migration as well as business logic migration, as long as the latter is designed with a service architecture in mind.

Regards,

Ricardo

I think the next Elevate conference is going to be all about this.

regards