Solved: Is there a future after PowerBuilder 12.6?

1,570

SAP Managed Tags:
SAP PowerBuilder

Could someone at SAP elaborate on this topic?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (1)

Yes there is, and it’s called…. PowerBuilder .NET 12.6!

PowerBuilder .NET takes advantage of the .NET Framework which is Microsoft’s next generation programming model and a response to Java’s success. So, this may be the most reasonable migration path for current PB shops as long as:

You don’t mind that your PB.NET applications will run somewhat slower than PB Classic due to the inherent architecture in which code is compiled just in time.
SAP improves IDE stability (it is still very buggy).
SAP improves IDE responsiveness (it is extremely slow to load a PB solution in PB.NET as compared to a workplace in PB Classic).
You are still committed to client server application development and don’t want to develop web applications (there is no functionality to do so in PB.NET).
You love the DataWindow and can’t live without it.
And most importantly, SAP shows full commitment to the product (Companies look for long term solutions and vendor support and commitment is very important).

What are the advantages of migrating to PowerBuilder.NET? Well, just to name a few:

You can take your PB code and migrate it to PB .NET and start working on it on the next day.
It allows you to use all of the .NET Framework class libraries like XML processing classes, Web Services classes, Security classes, etc., etc., etc. (see http://msdn.microsoft.com/en-us/library/gg145045%28v=vs.110%29.aspx).
It allows you to use third party .NET tools.
The PB.NET IDE is based on Visual Studio which is a proven IDE.
Artifacts are stored as separate files, which will make it possible in theory to use any source control system on the market.
And most importantly, you still get to use Powerscript (i.e. PowerScript.NET) and the Datawindow which leverages your current development resources.

SAP must continue to improve PB Classic which will let PB shops follow a seamless transition to PB.NET. By comparison, third party tool providers offer their tools as ActiveX (OCX) and standard DLL libraries as well as .NET libraries. So PB Classic should continue to improve alongside PB.NET if SAP wants the later to succeed.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Ricardo;

I am of the opposite opinion - EOL PB.Net all together. Here are a few thoughts:

1) PB Classic IDE is still way better in many areas (except Intellisense) - but, that could easily be improved with an AutoScript facelift,

2) PB.Net only has a 5% adoption according to the 2014 PB survey. 90+% of current PB Developers still use and plan to use PB Classic (according to the 2014 PB survey) only.

3) WPF is DOA now. Even my VS friends have dropped using it (not to mention my Canadian Government Clients). What was hot 5+ years ago is now passé!

4) 51% of all applications world wide are J2EE based. PB Classic can already do J2EE interoperability (have a look at the "create javavm" in PB Classic). It should be extended in that direction. Only 41% of IT shops world wide use .Net.

5) Most users and IT shops want Web Solutions not another native C/S application (aka WPF).

6) The direction for application development now is Web and Mobile - which PB.Net gives you no path. Whereas PB Classic + Appeon does it all.

7) What PB developers need is both J2EE and .Net interoperability - not another "silo" IDE to try and achieve that. PB Classic has being doing .NET before PB.Net was even written. SAP just needs to add WCF to Classic.

😎 PB.Net still can not do important things like proper OLE, PSR, PipeLines, etc

9) Maintaining 2 IDE's would be a waste of Engineering IMHO. Lets get back to what has always worked and that most developers use ... Classic. Take the R&D monies from dropping PB.Net and reinvest it in PB Classic. A much better ROI from my perspective.

10) SAP needs to get focus on what Appeon is doing in the Web and Mobile space. Appron only supports PB Classic.

11) Add JSP support back into PB Classic (it was there).

12) Add JScript to PB's PowerScripting.

13) The cost of fixing PB.Net's buggyness - not to mention the R&D expense and time - would not make new or seasoned PB developers use the product.

14) Quite a few DataWindow features are still not available in PB.Net that are working in PB Classic. Just add the graph types from PB.Net to PB Classic.

etc, etc

Regards ... Chris

The PB.Net IDE is just too <curseword> slow to be of any real productive use.

They would be better off re-writing the IDE in PowerBuilder to support Classic, .Net, Android, iOS using the new docking window feature of 12.6. The .IDE should include a .Net Winforms target. The code editor in the IDE should be .Net aware when editing a script in a .Net target. It should also generate directly to MSIL instead of C#. Conversion of classic targets to .Net should be Winform only, WPF should only be for new. And when creating the WPF painter in the new IDE, eliminate the make believe inheritance of the XAML files.

I agree with Chris and Roland entirely. PB Classic should be enhanced and extended to incorporate the features that are needed to keep pace with the market place. Sure, there are loads of things that could be done to make the product better, but as far as I know, there's not a perfect development platform on the planet. In the hands of someone that knows how to use it PB Classic can easily keep up with any development platform on the market today, and if with even token level of support from SAP it could be extended to be even better.

In my mind the biggest problem facing PowerBuilder right now, is that there's not enough people that believe that it can keep pace with other development environment options. For me, the most encouraging thing they could announce is the launch of a proper marketing strategy to get the perception of PowerBuilder back in line with how awesome the product really is.

Having one tool in which we can develop both classic PowerBuilder applications and .NET applications is something I've suggested in the past. That’s why my suggestion to migrate to PB.NET came with some big IF’s. IF SAP makes it faster, IF SAP gets rid of all the bugs, and IF SAP shows full commitment to the tool to increase its features.

PowerBuilder is a tool, not just a language. And as a tool it has done a wonderful job integrating two technologies, Windows applications and SQL data sources using the Datawindow. But software technology has followed new directions and PB has not been able to adapt to this changes. These include web development, in the form of HTML page generation and client side programming (e.g. JavaScript), and mobile apps development. The new paradigms involve not just two but three or more technologies which demand new tools so again we can easily develop applications that leverages those technologies.

But also the new .NET programming model for developing applications for Windows introduced by Microsoft in the beginning of 2000 signaled a clear direction as to where Windows applications development was headed in which standard, intermediate, managed code is produced by whatever syntax you like. So IF you don’t want to develop web applications and IF you don’t want to develop mobile apps then PB.NET makes good sense as a migration platform for current PB shops that currently develop for the Windows platform but are stuck with PB Classic and need the extended functionality of .NET.

I don’t see many differences working with the PB.NET IDE than with PB Classic IDE. I know it’s a different IDE but one should be up to speed in a week or two. The IDE is built so you are able to do the same as with PB Classic (e.g. the DataWindow painter is there). And I expect the gap between PB.NET and PB Classic to be reduced in the future until there is no difference at all. Maybe this will take SAP less time than it will take to rewrite PB Classic to enable it for .NET programming.

Answers (6)

Oracle's direction for Forms is an eye opener on how PB should evolve in the coming years. It is heartening to see how Forms, a Client/Server desktop dev tool is being transformed into a modern app development tool. Check out this webinar: The Future of Forms is ..... Forms (and some friends) (UKOUG, 2011 - with Grant Ronald) - AMIS Techn.... One of the bullets in Oracle Forms Strategy 'Bring Forms productivity to JEE world' makes it clear that when it comes to productivity, 4GL tools are far superior and there is currently no 4GL capabilities in Web development in the market. Instead of waiting for the market to keep coming up with some new stuff (web development is still at 3GL level even after 15 years), why not take advantage of the superior 4GL capabilities for app development.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

I think that there's no future.

Powerbuilder classic is more than outdated. I'm developing since 20 years, so I just can look back ~20 years. But development heavily changed in this time from write once to write --> change --> change --> change.

You can really fast create applications with powerbuilder that's right. But in my view they're not good. For me a good software is which is easy changeable.

So the key point is maintainability. It's no longer the key point to get things ready quick they have to be changed quick.

The projects I've seen written in Powerbuilder (just two bigger projects) are far far away from beeing maintainable, the complexity is still raising.

For me they're a maintaince nightmare, even the older PB devs are saying this. ^^

So as a tool for smaller applications like for tablets or mobile devices in general there could be a niche. But other projects (Android) or tools (Eclipse) or even languages (Java) are telling you where to go on mobile devices for mass consumer market.

Maybe there's a niche for smaller desktop applications written with powerbuilder, but full scale desktop applications are written in other languages with other tools which are around since more than 20 years (MFC and newer onces with .NET).

In my opinion SAP should decide weather they will support the .NET Framework and pump um PowerScript to a 100% compatible .NET language or not.

As a developer who writes desktop applications I don't need a product which is outdated and just get new features for mobile devices. Then I can switch and took the original (MS tools).

That PB is the mobile devices divsion doesn't really sound good for me.

Bad code is not an issue of the development language.

I am around with PowerBuilder since 1994 and have seen a lot of code.

There have been simple architected big applications easy to maintain. And complex architected nightmares. Worsed are those by C++ or Java coders writing PowerBuilder code without understanding the Datawindow.

But I agree, that the PB-IDE (Classic) needs some modern features to support refactoring like you have with Resharper for C# or have in the Eclipse IDE.

Hi Ganesh;

A great example from Oracle on how to rejuvenate a product for sure! Something that Sybase needed to do for over a decade now but never had the vision or the proper management in place to move the product forward.

Too many people thought that PB.Net was the answer - but, in reality Java & .Net interoperability was really the requirement with web and mobile added in recent years. Personally, I don't think that SAP is in a position or has the interest to move the PB product forward. Instead, I would recommend them giving the product to a software company that can accomplish this.

Regards ... Chris

RAD development does not mean that the applications created in PB are simple, rather it allows very complex data-driven applications with heavy maintenance requirements that can be handled effectively using PB. In fact, PB is by far the best tool for desktop windows development. Case in point, one of our Oil industry customers is using a major Asset management & Accounting windows GUI application that is entirely developed in PB and tightly integrated with Oracle 11i EBS. Customer does not intend to re-write this application in any other language or tool as they have significant investments in this tool over a period of 20 years and is only making further investments in maintaining this application. In fact, many ERP level applications available in the market are written using PB including Asset Accounting, Telecom Billing products to quote a few examples. Without the power of tools such as Appeon, it will be very difficult to replicate the rich functionality in PB to Web. It would take a while before some new Javascipt based framework can really reach 4GL levels in abstracting the plumbing needed. Most developers in web are still doing a lot of non-essential coding that can and should be avoided. A 4GL developer may not like the idea of writing code in a 3GL style but i am not sure if the opposite is true

@Ludwig

Sure with every language you can create crap, especially with the lower ones.

I belive you that the ones written by objectoriented coders are worse than written by procedural oriented coders. That's by the fact that they learned a totally different approch. So the concept behind the DataWindow (bring the data and the view together) violates everything they've learned.

That's basically OO vs. Procedural. We shouldn't discuss this here, that's done often enough.

There're pros and cons on every side for different solutions.

@Ganesh

Sure a customer is calculating twice. Why the hell should he invest money in something new when he got something working?

But the time comes and he wants something new.

What happens when your customer decides that he needs something new and you can't give him what he want's because your development tool is basically from the last century?

Or he's explicit asking for technologies, a small company maybe doesn't care but bigger ones with people who have an IT background are asking such things.

So when everyone of you here is reffering to PB I assume you mean the DataWindow. Which is the key concept used in PB applications.

Back in the early 90's the DataWindow maybe was something new and special. No one else have had something similar. They were the first like Apple with their Phones showing how to build a smartphone.

I will compare the DataWindow with MS Access 97 which is the best compare comes to my mind. What's the difference?

Both are easy to use.

Both can create reports and manipulate data with little to no coding efforts.

So even in the late 90's PB (the DataWindow) wasn't special anymore nor the best desktop development tool.

We should make clear what you mean with best and compare it.

You say that bringing new web fetures would help (that's what I understood you're saying). But I belive that this wouldn't help. Many customers want web applications, they're "in". But many (especially end users) won't so and arguing they're slower.

Just to give one example, why I think web isn't the solution.

MS the OS desktop leader tried to bring "web applications" to every desktop. The look and feel was like it was in a browser. The sales loved it. It looks cute, was something new etc.

But finally no one wanted this kind of application. MS gave up. The technology is still there, but no one really used it.

So when your customers are asking for a web application maybe this would help you. But others not. And these others have too look for other aproaches When they decide against PB it's bad because this means again a smaller community.

I'm working by myself with PB, so this shouldn't be any offense.

- But I don't see a growing community. I see a community which is getting older and older.

- I don't see a company which gives a clear statement, for the time after 2017(?). I see a company which forces people to look for alternatives just for one case.

My opinion is no one should think about what should/could/would happen with PB when they sell it for example to Appeon.

Everyone should think about what will happen when they don't and PB get's EOLed. That's what you and your company should be prepared for.

That's a good point. It is not necessary to webbify all Desktop applications. The application that i was referring to is a complex desktop GUI application and the End Users are happy with the application most of the time. Customer is not intending to migrate this app to Web anytime soon.

For scenarios, where the Customer wants the desktop app to be converted into a Web enabled app, the present crop of Web UI development tools (read Javascript based Rich internet application frameworks in the market) are not good enough and still not at 4GL level (i.e. more plumbing needed and Datawindow, PFC like features are missing) and would take a while, not sure how long. Appeon, however, excels in bringing PB's 4GL capabilities to the Web and that makes it cool. It also solves scalability issues inherent in a two tiered app by converting the solution into a n-tiered distributed web app, even though the same can be achieved using a n-tiered distributed PB app.

I agree that there are more options in the market today for Native desktop development including iOS, Android based app development tools apart from Windows. Also, there is a need for cross OS development. i.e. Windows apps running in Android and vice-versa. Clearly, Web (read HTML development) may not be the answer in these scenarios even though some of the folks seem to be promoting this. Applications hosted in Cloud may be the answer in such scenarios. i.e. you could run a Android app from a Windows based Cloud and vice-versa etc and the technology is fast maturing. For eg., RemoteApp from MS enable Windows apps to be run in Android etc.

Check out this two opposing views on the Native Apps (aka. Client/Server Apps) Versus HTML Apps (aka. Web Apps) debate.

http://searchenginewatch.com/article/2375397/Androids-New-Feature-Paves-Way-for-Apps-Replacing-Web

Could HTML5 Web Apps Mean the End of Native Mobile Apps? | Sencha Touch, PhoneGap and Mobile Dev Tut...

The direction that Mobile app development takes in the coming years is likely to influence all development (including Web development). If Native Apps succeed, it would indicate renewed interest in Client/Server development tools as well.

Forrester is endorsing Native Apps in this debate: Forrester: HTML5 apps still not as good as native apps | InfoWorld

It will be interesting to see how these two opposing views will eventually playout and how this will impact app development.

Hi Ganesh;

T^hank you for the interesting links. Yes, an interesting debate that has been going one for some number of years now.

Regards ... Chris

One of our major customers having a substantial investment in PB (i.e. 3 major financial products with 6000 plus GUI screens) is looking to migrate away from PB to a Java based framework. Appeon was not considered as they want to migrate to a specific Javascript/Java based framework. What answer SAP has for such customers?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Ganesh;

I am very surprised on that direction given the size of the application, complexity and stability that they did not consider Appeon 2015 versus a complete rewrite. The rewrite would mean a high risk of project overrun, delay, failure, & costs compared to Appeon (IMHO).

FYI: Great White North Technical Evangelist: Appeon 2015

Regards ... Chris

Hi Chris,

They are primarily looking at a combination of a tool based approach (converts from PB to Javascript\J2EE BENTO Modern UI\Bootstrap framework) and some manual refactoring. One of the key requirements is for the automation tool to convert Datawindows to Web BENTO Modern UI. They are evaluating some tools in the market that can convert automatically upto 60%. I totally agree that there are risks in going with this approach given the size, complexity and strategic nature of these applications. Even if they migrate to the target Javascript\J2EE based app, the cost of maintaining such an application will be atleast 3-4 times more than what it might be right now. I would appreciate any inputs on whether there were any studies done on developer productivity comparisons between BENTO Modern UI\Bootstrap framework versus Powerbuilder\Appeon. I understand that Appeon is a safe and superior option. If Appeon could have supported this Target framework, they might have considered it. However, as per feedback from Appeon, they do not support this target framework.

Thanks, Ganesh

I wonder what they plan on doing with the PB developers. Even if they retrain them, they no longer have in-depth knowledge of the code. The application will now be maintained by a group of developers that are all new to the development tools and have no knowledge of the code.

I visualize two things very clearly:

1 - there is a great interest in the PowerBuilder tecnology because of its productivity.

2 - there is a great interest in the PowerBuilder market.

yet not envision a clarity with PoweBuilder in own market.

we are awaiting clarity on this subject by SAP.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

do you guys have any news?

Seems we can chuck millions of line of code, huh?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Peter;

Yes, the lack of any concrete PB news at this time is very saddening - especially to IT management trying to make a decision on PB's future within their organization.

Regards .... Chris

Did you read the earlier responses in the thread, particularly at:

http://scn.sap.com/thread/3633252?start=0&tstart=14

yes Bruce, just wanted to know if Dirk Boessmann from SAP or someone else made some decisions public.

The background of my question is that i work for a company which develops in PB for some hundred customers. Will there be any SAP support for PB in the future?

We have to know how much time we have to migrate all our programs.

NO version 15 means NO more support from 2016(?).

it's the same for me here in italy.

I wouldn't expect SAP to make any official public announcements until sometime early next year. They simply don't operate quickly or openly.

Took the words out of my mouth, except not until Summer 2015 based on past performance.

"Summer 2015" => That would be about two more Appeon releases from now.

Peter,

If you can find the time to login to SAP's abominable nosupport site 10 times, you'll find that support for 12.1 ends in Nov. 2014, 12.5 is end of life in August 2015 and 12.6 is end of life in July 2017. This will be the first time I can recall when there will be only one version of PB in support and says quite clearly that there are no plans in SAP for PowerBulider beyond 12.6.

It's all very well for Dirk Boessman to prance up and down a stage and spout on what he's *thinking* about. (I should put a picture of Nero and Rome burning here). I'm afraid I live in the real world and am not prepared to bet my future or that of my business on the alleged musings of a some unknown in a company that blatantly has no interest in their customers beyond screwing money out of them.

I would suggest you do what my team is doing and look at alternatives to PowerBuilder. Sad though it is, I'm afraid SAP really have killed it, they just won't say so. We're not even thinking about a move to 12.6 - the trial migration I did on a target with four objects simply lost scripts, and reading comments in here it's bug ridden anyway. Given how little there actually was in it, why would you bother?

As for Appeon, everything you need to know is found in another thread on this group.... "appeon_workarounds.pbl"

Paul

See how long before the mods clobber this one

Hi Paul,

what kind of objects you lost scripts during migration? from which version to 12.6? could you share the sample codes?

Totally agree,

What would show SAP still takes pb serious, is making a new EBF to fix the bugs in 12.6.

Before, bugs were a lot more "public", now you just find them yourself. 3 reported bugs in 10 days, that´s enough for me. Now I want to see what´s done with it.

If nothing, then I think I know enough.

Appeon does look like a serious and capable company though ... there still might be some hope. (or Chris P. might even win the lottery! )

MiguelL.

Hi Miguel;

I just won $137 in my scratch & win tickets I got for Xmas ... So I'm definitely going to check my lottery tickets! 😉

I no longer believe anything SAP tells us. Dirk Boessmann promised at last May's conference that a contract with Appeon was his top priority and that he had a "team" working on it. A contract should be in place by the end of July - the end of summer at the latest. Here we are at the edge of 2016 and ZIP.

I'm now advising all my Canadian Government clients to stay away from all SAP products.

Regards ... Chris

Hi Chris,

Ha that´s great! I also won some Spanish lottery (120 €, finally!), but the only problem is that meanwhile, I´ve left Spain to accept a job in the UK, so don´t know how I´m gonna collect it . I wrote the previous message right after listening to the 2nd webinar of Appeon about Powerbuilder´s future. It might work out, but we´ve been harassed too much: first there was webforms 2.0, then it was taken out, now it seems we´re going to have something alike again. Lately I´ve been evaluating Appeon and I think it really is a great product, no doubt that powerbuilder will be better off in Appeon´s hands, but still "something" also tells me that .Net might be the way to go. According to webinar 2, powerbuilder will be able to do certain stuff through COM, but who trusts guarantees that in near future Microsoft won´t be making certain stuff obsolete? (OLE, Mapi, etc.)

"Something": Appeon also has a way of not being totally straight forward, so that´s not too convincing either: they´ve been telling me that "I can use EA Server to distribute pb nvo´s" but they suddenly forget to mention that EA server will be EOL soon. Then they talk about OData, other things and also 64bit support, but forget to mention that OData is not supporting 64 bit, just like Mapi.

For now, the company I work for, luckily wants to keep working with pb, but at the same time, we´re thinking of downgrading to 12.5 which seems a lot less buggy. The other day, when

1) reporting about Mapi not working well and leaving the executable running in the background processes of windows (after doing a send) the answer of SAP was that "on their computer everything worked fine". Oh yes... it does, once of every 20 executions, but still .. a lot slower.

2) Using "Data.primary.original", to replace the contents of a dw, results in sporadic "funny chinese characters", unless you assign it first to an "any" variable (in debug it might still show the funny chars). And I now also have to check first if there were any rows before using the "data.primary.original" since it´ll blow up if not, and last but not least of my previous 10 days working with 12.6:

3) There are differences in the compiler when checking the script of a script without ancestor and when you do have an ancestor:

This following code, compiles in the CHILD script, but will blow up powerbuilder IDE after exiting:

string ls_gonna_blowup

ls_gonna_blowup // invalid statement, but compiles, fills the string with again "funny chinese chars"

int li_dummy

string ls_should_be_an_empty_string

// put your debug stop right here:

ls_should_be_an_empty_string = ls_gonna_blowup

ls_should_be_an_empty_string = ls_should_be_an_empty_string // it´s NOT

In a parent script, it correctly warns about "invalid statement" in the child event, the same code is "okay" for the compiler.

Now I know, this is a very unlikely and unusual thing to do, but it sort of happened to me, putting the "// &" on the right instead of left, of a series of variable declarations, being slowly connected through vpn and the mouse pad being enabled. (in other words, I made a mistake that compiled perfectly).

What worries me about the chinese characters, is that fundamentally there´s something wrong with the memory protection/management/unicode? of datawindows, using DATA, and that the compiler is buggy. I also get the feeling that the behaviour of pb IDE and EXE are more different than ever before.

Let Appeon take over PB now and "do well" on a short term, or I´m afraid people are going to avoid it as hell.

When I´m hearing all of the awaiting changes for PB that appeon has in mind, it seems hard to me to trust in the "do well on a short term", since the product at this stage is too buggy to simply take over, it first needs fixing.

I´m waiting for a few weeks to see what SAP does with my reported incidents, but if nothing comes out, I´ll seriously recommend my bosses to step back to 12.5 and stay away from newer versions until they prove stable and solid.

Kind regards,

Miguel Leeuwe

(so ... if we put together out lotteries and wait long enough, we even might be able to buy the pb product )

Hi Miguel;

FWIW: All my Canadian Government clients are holding on PB v12.5.1. We have completed a lot of extensive testing over the past few years and found that this version was the last stable release for the best production use.

The problem with 12.5.2 was that the WebForms feature was just blindly yanked without serious testing to see the side effects. These problems were then transposed into v12.6 which then compounded the situation by adding dockable Windows and some undocumented features with no proper Beta testing.

The other major problem with v12.6 is the lack of proper maintenance releases (aka Service Packs) that have been fully regression system tested. Instead, only EBF fixes have been released that while addressing specific issues have created other undesirable side effects. So what we have now is a non-usable production ready version.

Even scarier is the possibility of giving the v12.6 source code to Appeon by SAP. This would first severly handicap Appeon in putting out a stable release without some serious code fixing and proper public testing (which PB 12.6 never had).

IMHO, SAP should be on the hook for cleaning up PB 12.6 ASAP and also giving Appeon some serious monies in order to allow Appeon to fix SAP''s mess before they can move the PB product forward.

Regards ... Chris

Miguel,

Thank you for watching the second Webcast! During this Webcast we made it clear that NVOs would deploy to IIS not EAServer, and there is an FAQ that goes along with this video that clearly states EAServer customers should consider deploying NVOs to IIS (because most people know EAServer is EOL). I seriously doubt it was an Appeon employee who told you you should use EAServer!

Regards,

Armeen Mazda, CEO

Appeon Corporation

Hello Armeen,

I was not referring to what was said in the last webcast, I referred to "Appeon didn´t always seem a 100% clear" (in my opinion), like when talking about OData and 64bits support in the same sentence. Hopefully I´m wrong.

I was evaluating Appeon´s product itself (so not what powerbuilder will be able to do as a future Appeon product), and spoke to someone who sells the product and answered one of my questions this way:

Hello Miguel,

.....

Appeon can support the following application server: WebSphere, Weblogic, EAserver, Netweaver and IIS, you will find the Appeon system requirements here

NVO's are only supported by EAServer, all the other application servers doesn't support it. Please be aware that EAServer is End Of Life and that we advise to use a different application server.

....

So while previous is a clear answer, I didn´t find this limitation to EAServer clearly indicated everywhere in the documentation. (I see now, that it has somewhat improved in the 2015 documentation for Appeon).

Then again, I also made a similar question after the first webcast and this one was answered by an Appeon employee (you also received that email of 5th of Nov. in CC):

"Hi Miguel,

Thanks for participating in our Webcast on the future vision for PowerBuilder. We appreciate your feedback about the Webcast. Please find our response to your questions/concerns below:

Q: I heard that EAServer will be end of life soon? If so, why would it be "a good migration path?"

A: "PB 12.x.NET" has the ability to deploy PB NVOs "as Web services" to Microsoft IIS server. Please evaluate PB.NET version 12.6 to deploy your NVOs as Web Services to Microsoft IIS server. After you have tried this please provide us your feedback so we can continue to improve this feature for you.

So while I appreciate the clear answer, now "suddenly" when talking about NVO´s deployed to the server, we are meaning WebServices (unless we do have EAServer and NVO´s are NVO´s). Add to that the small detail of having to be pb .Net. I don´t know if it will be possible to have a pb classic application, converted by appeon, consume pb.Net web services. (I really do hope so).

I say "suddenly" because I´m an absolute vegetable when it comes to webstuff and people like me might be confused, since this information has, either totally escaped my attention, or simply hasn´t been clearly stated by Appeon when talking about nvo´s as a workaround for unsupported powerbuilder features..

Nevertheless, I´m happy you responded and I do have a strong feeling that the best thing to happen to powerbuilder is be in the hands of Appeon (except for price tag maybe, no one knows) .

Please consider also Chris P.'s valuable advice: to not build any new product on top of the ruins of pb 12.6, but sort of start from 12.5.1.

Thanks and kind regards

Miguel Leeuwe

So just to be clear:

My statement of Appeon not always seeming 100% clear was based upon previous information. (to be honest, I´m not that sure if it was after the first webcast of "powerbuilder´s future" or after watching some other Appeon video, but it was Appeons').
I´m happy that in the 2nd webcast more clarity has been given about the topic.

I´ll just see what happens, while waiting for SAP´s EBF´s for 12.6 or maybe going back to 12.5.1

Hi Miguel;

FYI: IIs is most likely not a plausible migration path for existing EAS customers that run PB NVUO's today. I suspect that they don't realize the features in EAS that IIs does not support, like:

1) Start-Up NVUO processing.

2) Shared memory NVUO's that can be accessed by other NVUO's

3) Dynamic NVUO to NVUO calling

4) Cross server NVUO calling.

5) NVUO multithreading (Activate/Deactivate events)

6) Shutdown NVUO processing.

7) JSP interaction

😎 calling Java beans directly

9) NVUO refresh (CanBePooled event)

Etc (I've probably missed a few other minor ones)

It would be nice if the Appeon Server add-on support for NVUO's directly and in particular, these types of EAS processing features listed above. However, it would be no small task for Appeon to add these features into their repertoire.

FWIW: If Appeon brought back the old Distributed PowerBuilder - we could do all the things that I listed EAS does today that IIs does not for NVUO's in DPB (except for the JSP interaction). However, add an Apache Web server to the DPB server mix and we can get back to the JSP world using my EAS framework. The EAS framework was a forward engineering of my original DPB framework - which I could easily resurrect. 😉

Regards ... Chris

PS: EAS is EOL (no new development). All support ends very soon.

Aha, so definitely there is an impact of EOL of EAServer which can´t be easily taken over by simply using webservices in IIS.

Luckily we aren´t using EAServer at all, so we won´t suffer that much. We´re merely looking at the webcasts to see if APPEON is going to be a solution for potential clients and what´s going to be of Powerbuilder, when it runs as a Visual Studio plugin. We do want to go web and mobile and Appeon seems a good option. I do wander how long it´ll take for Appeon to be up to date with a new powerbuilder(-plugin)? Maybe things will be done well and Appeon will be immediately adapted to work with the new future version of powerbuilder. Maybe appeon won´t even be necessary any more for certain clients that might want to work with our apps from a tablet or mobile...

Let´s just see what the third webcast brings.

Thanks for all of the valuable information given, l wish you and everyone on this forum the best of best for 2016 !!!

Cheers,

miguel L.

Yes, EAS's feature rich environment is very hard to fully emulate in IIs. Only when you have worked with EAS extensively like I have (and taught the PB/EAS courses) do you realize how robust this combination are. Of course, Sybase only killed DPB to force people to buy EA$. If we still had DPB today, it could easily whip EAS in performance as it was a pure C++ execution model vs EAS's Java Bean emulation wrapper around NVUO's that we see today.

Note: Older EAS's treated NVUO's directly as C++ objects.

FWIW: Well have to see what Armeen's detailed application architecture is in the next set of Webinars to see exactly what his VS plug-in vision contains, how this can move the PB product forward and the time frames expected.

Hi Miguel,

The documentation and the responses from our staff look correct to me. Unfortunately, we still have many customers using our product together with EAServer. Since existing customers can still get EAServer support from SAP for additional period of time we still need to refer to it in our product documentation. We apologize for any confusion this has caused.

As far as PB NVOs deployed to Microsoft IIS, we are aware that there are some differences in the implementation between what PB provides out of the box for Microsoft IIS and what EAServer provides. In the future, we are looking to minimize this gap and support an RPC from the PB client that doesn't have the overhead of a Web service.

But for now, what is IMPORTANT is that customers evaluate deploying PB NVOs to Microsoft IIS with PB 12.6 and then give us their feedback. Assuming in the future Web services will not be the only way to call server-side NVOs from a PB client, what we need to understand is are there any critical feature missing to make the solution usable (not perfect or exactly like EAServer)?

Regards,

Armeen Mazda, CEO

Appeon Corporation

Hi Armeen;

May I also suggest that PB Developers look into using my Web Service framework for PB NVUO's as well. The framework greatly accelerates the development speed of WS components. The framework is also free & open source.

For those PB developers who have used my EAS framework, the WS framework is a forward engineering of the EAS one. So reworking an NVUO from one to the other is relatively easy.

Also, the WS framework contains many examples of WS functionality built using the WS framework. Hopefully, these will also assist EAS and new WS developers in assimilating the WS & IIs environments.

Framework

Examples

Regards .... Chris

PS: Feel free to contact me for a copy of my presentation on WS creation using PB Classic.

Yes, we definitely want customers to try all possible ways to deploy PB NVOs to IIS and give us feedback if major issues so we can try to make this a good solution for creating n-tier apps.

Ludwin,

Please post the details from the meeting and any interesting comments from other members in the User Group here. There is concern in the US over the lack of information concerning future development, so any and all news is always appreciated.

Best to all,

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Kyle.

We had Dirk Boessmann from SAP on our meeting and this is what I kept in mind:

Dirk Boessmann is Senior Vice President, Head of Mobile Platform Development. For what reasons ever, PowerBuilder is in this section. His business is mobile and as far as he sees now, PowerBuilder does not fit in to it. So he - in a way - inherited PowerBuilder but he is now looking for a sustainable solution to keep PowerBuilder alive.

This was mainly the topic of the session. Not discussing a roadmap.

The important news is:

End of Life is ruled out!

Certain components might need a managed end-of-life. This should not be an issue if there is a reasonable path forward. He mentioned EAServer as an example.

There was a look towards moving everything into HANA, but they have determined that it's not a step for everyone.

They are currently getting an understanding of what it takes for the next 2 or 3 years and what is needed to give it the next boost (4 to 7 years).

He figured out 6 possible scenarios in a - what should be considered as - "theoretical discussion":

Make PowerBuilder open source.
This option is largely ruled out (90%), though he's willing to be presented with a viable scenario.
This is because of most Open Source projects fail right after their start. And that’s not what they want for PowerBuilder.
Keep it in his business line and bring it up full steam within SAP.
This option carries the risk, that one day he could leave and his successor dislikes PowerBuilder and we start again where we are right now.
To outsource the development to a trusted partner and keep the brand an intellectual property (IP) at SAP.
The risk is that the external company goes away. In this case SAP has not the knowledge to take the development over again.
To OEM it to an external partner but keep the brand and IP at SAP.
The risk is similar to option 3.
Keep the IP and give the development and the brand (or the right to brand it differently) to an external partner.
This carries the same risk for SAP when the partner fails and SAP has to step in.
To give all of PowerBuilder away to an external partner.
This means that SAP is out of responsibility for PowerBuilder but that they have the risk that SAP cannot do anything anymore for PowerBuilder if this company fails.

Currently no decisions are made. Dirk Boessmann wants to have it done soon. But as SAP is a big company this could easily become a 5 month frame.

Danke Ludwin!

Thank you Ludwin, always appreciated.

One IMPORTANT THING to add!!

Dirk Boessmann EXPLICIT quoted out that all is under discussion!

He is NOT allowed to make an official statement!

Everything is in discussion!

SAP has follow a lot of compliance rules like Sarbanes-Oxley and others!

So no employee is allowed to do any official announcements that have not passed the board!

So this is not an official announcement he made, but sharing the status!

Thank you, Ludwin

Thanks Ludwin. They seemed to have some sort of a strategy back in May to make PB to be a part of the realtime data management platform. Are they going back on this again? What is the reason for going back on this? Can someone at SAP make it clear? Appreciate it.

Hi Ludwin;

Just one observation ....

=> Dirk Boessmann is Senior Vice President, Head of Mobile Platform Development. For what reasons ever, PowerBuilder is in this section. His business is mobile and as far as he sees now,

I wonder what he thinks of PB Classic + Appeon Web/Mobile which targets his area perfectly ... especially now since Appeon is Hana enabled as well?

Regards ... Chris

Hi Chris,

I don't know what he thinks.

He stayed and watched Armeen's presentation. But we had no chance to talk about it.

I think that he understood what Appeon is doing. Especially that they have a C++ PlugIn and are not doing HTML5.

Every word more from me would be pure speculation!

Yes, on the web side HTML5 compatibility would be nice. However, Appeon is really based on an "Appcellerator" technology design which replies on either the web browser plug-in or an iOS/Android "shell" (AWS - Appeon Work Space) to run the PB code like a native application in each environment.

At least Dirk saw Appeon - which at least will give him (hopefully) a better appreciation of what it can do to enable PB on other platforms. 🙂

Thanks Ludwin for your thoughts.

For those that aren't from the US, the Sarbanes-Oxley Act relates to board members being held personally responsible for the accuracy of corporate financial statements.

5 months in SAP time?

As far as #6 goes, an external partner couldn't possibly manage PowerBuilder any worse than SAP or Sybase have done so I don't see that as a risk.

If I hit the lottery in the next few months, I am thinking of putting in a bid for it.

Yes it is!

Wait until next week.

DIrk Boessmann, Senior Vice President / Mobile Developement / P&I Technology , SAP SE will explain it to us at the PBUGG meeting in Berlin.

Stay tuned, Ludwin.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

So we are looking forward for an update, Next week.

Andreas.

Can we post here some of our questions, so if you find them interesting you can communicate for as?

Andreas.

Post away; The meeting is about to start. Dirk is scheduled to speak at 2:00 PM (German time), which is in about 4 hours, so post quickly.

Hope that others will also post their questions.

We want to know if there are any plans for PB.NET.
If there is any future for PB.NET they consider to provide project types for mobile like xamarin does? I know this may require a datawindow rewrite...
In pb 12.6 we had some missing features, compared to what was originally announced after 12.5 was released (grid/grid control, native pdf support). They do consider to provide those features (or some of) in a future release?
SAP sells the product but requires a support plan to provide even minor releases (I have one). But this seems like they sell it without any software assurance (not even for a limited period ex: 3 months). Are they considering to rethink about that? They understand that this, imho, will not help the product?
Are there any plans from sap to give powerbuilder developer a way to deploy to the web? Or our only hope will be to use third party software? There were some demos of datawindows deployed to html5. What happened to all that work?
Are still plans to support other platforms (linux, mac os e.t.c.)?
If they are really planning to continue developing on pb, in what time frame we should expect new major releases (in the past we saw new release comming after 18 months, sometimes even sooner).
Are they considering to make some improvement in pbscript for pb classic - native?
We need documentation. Lack of documentation is an issue. Help isn't good enough (from 12.5.x and later)
If they decide to stop development of PB.NET (which I believe it's not used because it is buggy and not because pb developers doesn't want to use its targets), what will happen to available targets? They will be discontinued (I know that there were rumors that wpf and xaml are dead, but in last VS we see some improvements, and they seem to reconsider wpf for desktop).

If you believe that any of the above has to be answered and nobody else asks, then ask.

Anyway, thanks Bruce.

Andreas.

Don't know if it's too late, if not:

What is the plan for service patches for 12.5 and 12.6?

Thx, Bruce

Dirk has presented and left. I did ask about maintenance releases and EBFs. I'll cover that when I write up my notes on the meeting.

Mark and Scott, that was...Classic! I will be coming back to this post when I need a good laugh...as long as it doesn't get axed by the moderators.

Chris Craft

Are the thoughts of DIrk Boessmann, Senior Vice President / Mobile Developement / P&I Technology , SAP SE going to be shared with the PowerBuilder community and customers, or was it just a bunch of secret slideware for the German User Group?

I'm sure Ludwin will post something soon. I'll be posting as well once I'm back in the US. Right now I'm in Zurich with the Swiss user group.

Ask a Question

Top Q&A Solution Author

User

Count

Is there a future after PowerBuilder 12.6?

Accepted Solutions (1)

Accepted Solutions (1)

Answers (6)

Answers (6)

Re: Still unable to pass DateTime parameters with ...

Re: Still unable to pass DateTime parameters with ...

Re: CR2020 viewer print output is incorrect when P...

Re: Still unable to pass DateTime parameters with ...

Story Calculations in SAP Analytics Cloud