Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (5)

Resolved Target audience of .Net related changes

  1. Misc
1
Votes
Undo
  1. Konstantin Goldobin
    Konstantin Goldobin
  2. PowerBuilder
  3. Monday, 18 November 2019 10:13 AM UTC

Hello,

I am not a C#, .Net, or web developer; I've been doing PB only since 1995. Now, I watched the first three KeyNote replays from Elevate 2019 and understood close to nothing in them. So, I can't help asking myself: who is the target audience of these presentations? And not only presentations but the changes themselves. Is Appeon trying to attract people who are doing web development now but who are using other tools?

Best regards,
Konstantin

  1. Elevate Conference
  2. PowerBuilder
Pipeline from JSON
Connect to ASE through PB2017R3 or PB2019R3.
Responses (5)
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Monday, 18 November 2019 12:16 PM UTC
  2. PowerBuilder
  3. # 1

Hi Konstantin,

Requests for cross O/S server side software components are very common these days.

So is replacing the legacy PC front-end with mobile or web-based front-ends. And therefore desire for gradual migration from client/server to individual services accessible from both PowerScript and any other language. 

Appeon's response/solution is based on .NET Core as the cross O/S platform and REST-services based on ASP.NET Core on top of that. I believe these are wise decisions!

PowerScript remains great for data intensive client/server apps on Windows. 

HTH /Michael 

 

Comment
There are no comments made yet.
Armeen Mazda @Appeon
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Monday, 18 November 2019 15:19 PM UTC
  2. PowerBuilder
  3. # 2
Hi Konstantin,
 
The new .NET things Appeon is doing is focused on two customer segments:
 

1. PowerBuilder Developers - fastest migration possible of existing business logic from PowerScript to C# APIs.  

2. C# Developers - a much simpler and more productive alternative to Visual Studio and Entity Framework for developing C# APIs.

Michael outlined some of the reasons why PowerBuilders developers should consider to API-enable their apps, but there are many reasons to do so.  I think this article from Deloitte adds to Michael's points that it is imperative to API-enable: https://www2.deloitte.com/us/en/insights/focus/tech-trends/2018/api-program-strategy.html

There is always some learning curve with new technology or even a new feature for that matter; but I would argue that is not huge gap for a lot of PowerBuilder developers since the C# coding is centered around DataWindow technology.  Just take a look how similar the PowerScript and C# are using the .NET DataStore: 

Probably the real learning curve for PowerBuilder developers is not C# coding itself when using the .NET DataStore, but rather understanding how to shift programming style from client/server to Web APIs.

So long story short.... we are going after both PB and C# developers.  Yes, this stuff may go over some PB developer's heads, but if you decide you want to API-enable your app we make it as easy as possible!

By the way, thank you for taking the time to watch the conference keynote presentations.

Best regards,

Armeen Mazda
CEO, Appeon

Comment
David Peace (Powersoft)
  1. David Peace (Powersoft)
  2. Monday, 18 November 2019 16:01 PM UTC
One of the strengths of the PB community is the depth of knowledge that it readily available on the forums and through partners. Developers looking to make the jump across will find a huge amount of support, unlike the C# Visual Studio world where the majority of posts are offering out of date solutions or they are fundamentally flawed and do not work.



I think that there are many reasons to embrace the PB C# development. Not just within C# it's self, we are finding great uses for the innovations that have come into the native PowerScript and DWs that are solving real world problems for us now. All of the JSON changes have lead to us developing a remote data messaging service that allows thin client applications to use data residing on database hidden behind firewalls or NAT routers without any changes to the firewall. All over HTTPS with push HTTP messaging to the Database Service.



You do not have to go C# unless your application needs it.



Keep up the good work Appeon.
  1. Helpful
Konstantin Goldobin
  1. Konstantin Goldobin
  2. Tuesday, 19 November 2019 15:00 PM UTC
Hi David! Could you maybe tell us what is written in PowerScript in your example: thin clients or the service?
  1. Helpful
There are no comments made yet.
Olan Knight
Olan Knight Accepted Answer Pending Moderation
  1. Monday, 18 November 2019 19:15 PM UTC
  2. PowerBuilder
  3. # 3

Don't feel alone, Konstantin, because I find myself in the same boat.  Much of what I saw in the presentations, and a great deal of what I read in this forum is simply beyond my knowledge level.

In addition, I'm trying to get my company to migrate to the new PB, but that's a long, slow, difficult slog. Which means I don't have the time to play with the new code to learn it.  Work is crazy enough as it is.  :/

I try to keep as up to date as possible by keeping up with these forums and contributing where I can.

 

Later -

Olan

 

Comment
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Monday, 18 November 2019 22:59 PM UTC
Same here, though there are some good examples somewhere. My biggest no-no has been that "my" company would have to be convinced to run things on IIS, which means extra install, etc. Also it won't be faster than our current fat client. Then ... the challenge of going ORM, that's something that I myself don't see happening very smoothly. We just have so much SQL everywhere and have constant changes in views, tables, datawindows, not sure if it's going to be very helpful or just another "https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/"; .. We don't use tedious designs, data models, documentation "is not" ( feels like heaven though :), we just code along and they've been doing things like this for 15 years with success now. Going ORM would mean too big an effort and based upon missing information, I'm not even sure if that would be possible. Truly fear the day that one of my colleagues will retire though. So I'm still looking at how to - little by little - start migrating things at least to centralized nvo's / SnapObjects.but initially have to step away from ORM.



Maybe I'm wrong and ORM would save us a lot of time in the future, but the way I see it, when doing modifications you have to change things in more places: the database, the model, the datastore / datawindow and the code itself, meaning there's more change things are forgotten, not updated, etc.
  1. Helpful
There are no comments made yet.
Konstantin Goldobin
Konstantin Goldobin Accepted Answer Pending Moderation
  1. Tuesday, 19 November 2019 12:17 PM UTC
  2. PowerBuilder
  3. # 4

Hello Armeen,

Thanks for answering! I wouldn't expect any CEO to bother with posting on forums, so I really appreciate you doing this!

The "business logic" seems being mentioned all the time in migration-related presentations, and I trust you have seen examples of PB apps that do have some sort of a layer with non-visual objects implementing "business logic". In my personal experience, however, all "business logic" a typical PB app has is a number of data validation checks tied to datawindow controls. Am I right saying that such apps do not have anything that can be migrated to the application server level? (And BTW, are C# APIs hosted in IIS? I'm yet to watch a presentation that explains how these C# APIs are compiled and deployed...)

Another thing is user authentication and authorization for APIs calls: is it out of the scope of migration and should be taken care of independently by C# programmers? I guess this topic couldn't have been addressed in those short demonstrations, but what is the assumed strategy?

Best regards,
Konstantin

Comment
Michael Kramer
  1. Michael Kramer
  2. Tuesday, 19 November 2019 13:15 PM UTC
Validation even in DW control's ItemChanged, ItemError, and such still are worth moving to server-sider -- or -- duplicating at server-side. I would say a LOT of PB apps started some 20-25 years ago. A LOT of those see mobile and web siblings being developed. You basically have three ways to do validation in these:

1) Move all validations into the database using stored procedures -- with inherent risk of now having DB as an even heavier bottleneck.

2) Ignore all existing code and code the validations once again from the ground up -- with all risk of duplicating logic -- or having different logic for same data across input apps.

3) Extract validation logic from existing code; wrap such logic behind a common API; and call that API from all clients. This is where Appeon's approach aims. Migrate DataWindow objects, ease migration/conversion of PowerScript code, easy/fast interop from PowerScript client to server-side logic using modern APIs like REST using JSON.

App I'm working on today all this extract and reuse is irrelevant. However most of the apps I worked on for the last 20 years now have web siblings and/or mobile siblings.
  1. Helpful
Konstantin Goldobin
  1. Konstantin Goldobin
  2. Tuesday, 19 November 2019 15:06 PM UTC
Hi Michael! I'm sorry for asking a potentially dumb question, but wouldn't moving of data validation to an application server mean that clients have to send the content of their datawindow controls over to the server just for validation (and maybe then again for actual saving?) whereas the clients already have them?
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Tuesday, 19 November 2019 15:09 PM UTC
Yes, user authentication is important and the tools don't automatically do that for you. These are standard REST APIs so you can use whatever authentication solution you like that is compatible with .NET Core. On the client-side, the new RESTClient object in PowerScript supports various token technologies, such as OAuth and JWT.

Yes, refactoring of business logic needs to be done since most apps we have seen don't have things logically separated or encapsulated in NVOs according to best practices. Your app may not have much non-visual PowerScript and embedded SQL, but we have seen other apps that do. So there are apps out there with more than just data validation.

Since it is common that business logic needs to be extracted out of the app, this is one of the reasons that the PowerScript Migrator converts function-by-function. But of course, if you have an NVO object you can feed that entire object to the PowerScript Migrator. What you can't do is feed the PowerScript Migrator an entire app and expect to get proper C# out of it.

As far as where the data validation should go, there are different philosophies and also it is very project specific. So we don't want to make any blanket recommendations. But as Michael pointed out, there are a number of options, such as moving the data validation to the server side or keeping that at the client side.

If you do decide you want to API-enable some piece of your app, even if just small piece, since you mentioned you "understood close to nothing" I would highly recommend engaging one of our consulting partners for some coaching, mentoring, and producing a proof-of-concept. https://www.appeon.com/consultants/consulting-partners
  1. Helpful
There are no comments made yet.
Ricardo Jasso
Ricardo Jasso Accepted Answer Pending Moderation
  1. Wednesday, 20 November 2019 16:57 PM UTC
  2. PowerBuilder
  3. # 5

Hi Konstantin,

The .NET related changes Appeon has been making are targeted to the following audiences in my view:

1) PowerBuilder developers who want to cloudify their existing applications. This means that instead of directly accessing a data source like SQL Server calls are made to REST Web Services which in turn access the data source. No changes are made to the visual aspects of our native applications but now they can access a remote server on the Internet as if it was located on a LAN with no need to enable often blocked ports like 1433. Our new PowerBuilder applications are not converted to web applications but take advantage of web communication protocols and features.

2) PowerBuilder developers who want to implement Web Service API’s (Application Programming Interface) for their business logic. This means that the system’s functionality can now be accessed programmatically by other applications. With the new changes we can transport our business logic from non-visual PB objects to .NET objects and make them accessible through web services, again taking advantage of web communication protocols and features. The catch here is that we need to first API enable our business logic and change it from a stateful to a stateless form so it can be deployed as a Web API.

3) PowerBuilder developers who already have API’s for their business and data access logic but on a Sybase’s Enterprise Application Server (EAS) and want to migrate to IIS for business reasons (EAS has been discontinued). The path is easier than 2) because their business logic has already been API enabled.

4) .NET developers who want to use the new .NET DataStore to replace traditional ADO.NET components for data access. Appeon is clearly separating the presentation layer (capture, edit, validate, present) from the data access layer (store, retrieve, update, delete) in the new .NET DataStore and now it can be used by .NET developers. (I’ve been doing some tests using Visual Basic.NET and it looks promising).

What this is not about is migrating our whole PowerBuilder applications to .NET (desktop or web). This would imply migrating all the visual and non-visual aspects of our applications to .NET using standard and new libraries. Sybase aimed to achieve this goal with PowerBuilder.NET but the implementation was incomplete and unstable. And I don’t see this in Appeon’s future plans discussed so far.

In conclusion, the .NET related changes will help us cloudify our applications and/or create .NET Web API's that can expose business logic to other applications. All this with the new .NET DataStore and the new PowerBuilder web objects like HTTPClient, JSONGenerator, JSONParser, etc.

Best Regards,

Ricardo

Comment
Konstantin Goldobin
  1. Konstantin Goldobin
  2. Tuesday, 13 April 2021 06:57 AM UTC
Hello Ricardo! Could you please estimate how slower the path "client-web service-db server-web service-client" is comparing to "client-db server-client"?
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.