Please not another ABAP vs. Java-Thread, BUT ...

[Former Member]

Hi, folks!

I already had several inspiring discussions about the need for 2 different languages within one Enterprise System, but right now I' d like to take a more personal approach to this matter.

I' m working within SAP business for about 3 years now and started as a trainee for SAP Java development in a small consulting company . In my first year, I was some kind of geek freaking out on each new SAP technology that arose or was only announced. Web Dynpro Java, ESA/eSOA, Portal, Mendocino/Duet, Business Client, Enterprise Search, Widgets a.s.o. I did a lot of presentations and technical workshops for SAP Pros - NWDI, WDJ, Interactive Forms - and you know what? Nobody was interested in any of these. Interactive Forms? We just switched to Smartforms. WDJ? When will it be available for ABAP. NWDI? We spent a fortune on ABAP courses. Widgets? We have SAP GUI. Business Client? We have SAP GUI. Portal? We have SAP GUI.

Now I' m working as a simple ABAP programmer in HR. No web enablement, cause web apps are realized completely outside SAP. No SOA-enablement, cause all SAP functionality needed outside is either already provided via BAPIs or put in RFC modules. No Java at all, cause there is and will be only an ABAP stack. None of all the new stuff, but a great need for knowledge of standard programs, their configuration possibilities and use.

So, to come to the conclusion: What I realized in my work life is that daily business is pretty innovation-resistant and I personally don' t think that even half of all the "emerging technologies" will make it for the next 5 - 10 years. What I also realized is that a lot of time and work has to be spent by developers to keep in touch with new development techniques, which could be used better for clearing white spaces in classical ABAP as well as module programming environments. If developers would focus more on ABAP and module knowledge than on the newest Modelling-techniques many SAP systems probably wouldn' t be spoiled by poor custom developments, enhancements and modifications as they are today!

Regards,

Thomas

[ChrisSolomon]

I *STILL* stick by my prediction from wayyyyy back in this old post....

Where I state...

My opinion...very much to the contrary. Yes, wayyyyy back in 2001 or so when SAP made the announcment to a full on push to Java, lots of folks, especially ABAPpers got nervous (remember how many articles,books,etc have been written for ABAPpers to move to Java more easily? and many of them sprang up very quickly at that time). Well, then there was the whole story that came to pass where Microsoft was looking keenly to purchase SAP. In the end, both seemed to say "our technologies don't mesh well so not right now" and there was an amicable split. Think about it...it would look mighty strange for Microsoft to buy up a very Java-centric company at that time (they were then just pushing .Net big time). Now, from folks I talked to "on the inside", they said that at that very point, a LOT of work began to yank Java out of everything SAP and get it back to a more "Microsoft friendly" state...so to speak (for example, reworking the WAS to a different kernal removing the Java bits from where possible). Also, you saw the nice "partnership" come around the same time as Microsoft and SAP developed (and continue to) "Duet". Fast forward (a short time?) to now, and you see this (strange?) push from SAP again to move everything towards WebDynpro for ABAP (in fact the ESS business package is being retooled to it!). Sooooooo for my view on this....personally....I think SAP is setting itself back up for another move from Microsoft (and yes, wouldn't Oracle/Larry Ellison just crap themselves over that! haha). Again....just my speculation....or day-dreaming...or whatever. But anyways....no, I don't think ABAP is going anywhere anytime soon.

Haven't we been seeing some of this? NWDI being pushed out (yes, you can put Java development onto transports now) Java Webdynpro apps being ported to ABAP Webdynpro (T&E, HR Administrative Services and parts of ESS and MSS already).

[Former Member]

Chris,

Another interesting thing that I learned at TechEd last year. I don't know if everyone remembers when SAP announced project Muse. But this was to be the latest front end tool developed using Adobe. What was project Muse is now the new Netweaver Business Client. I sat through a presenation at Tech Ed that said that the Netweaver Business client was not delivered using Adobe technology but it was built on a Microsoft Platform. I asked a question about why the move away from Adobe and didn't get a real clear answer.

Best Regards,

Chris H.

[Former Member]

Chris,

I fully & totally agree with you, simply because of one thing: Every SAP comment on the Java/ABAP war - and for me it is something like a war, because there' s are warriors (the developing communities), weapons (WDJ/WDA, CAF, Portal ...), warlords (the "Evangelists") and a military objective - safeguard the own interests and means of income - points into this direction.

TJ (Mr. Jung that is ) often pointed out that SAP as well as their customers would use the technology in which the code base is realized as well as the developers skills are focused on. So, which is the most widespread SAP product and in which language have SAP developers - in Waldorf and around the world - been taught and working for decades by now? Not the Portal and JSPDynPages, I guess.

So, to me ABAP seems the base of SAPs most important product, the technology customers spent a fortune in and most SAP developers are earning their living with.

If I' m correct and if it is true, that by now ABAP' s capable of nearly everything Java also is and of many things Java will never be, then WHY should Java development ever prevail against this overwhelming opponent. It is already fighting a futile rearguard action!

Edited by: Thomas Würcher on Apr 30, 2008 10:06 AM

[Former Member]

> If I' m correct and if it is true, that by now ABAP' s capable of nearly everything Java also is and of many things Java will never be, then WHY should Java development ever prevail against this overwhelming opponent. It is already fighting a futile rearguard action!
> 
> Edited by: Thomas Würcher on Apr 30, 2008 10:06 AM

I agree, I think Java should just raise the white flag for performance alone but I am not complaining as have been an ABAPer for over 10 years now. I reckon Java is for the uber-geeks amongst us.

[ChrisSolomon]

@Chris H.

Wow....they (folks at TechEd) must have felt Deja Vu! I asked the SAME thing at their little "pod" presentation on the coming Netweaver Business Client!!! too funny. From what I gathered in the LITTLE they said, it is all .Net based and sits in that space between a thin(browser) and think(traditional SAP GUI) client. When asked why they went .Net and would it be supported for MS platforms only, I got "crickets". 😃 It will all be very interesting to see how this unfolds. When it does happen, I hope folks return to my post and talk about what a grand visionary I was (haha...con men, doomsdayers, and technology journalists work the same way...the make a 50/50 prediction...if wrong, no one much cares...if right, then "it must be a miracle! this guy really does see the future" ).

[thomas_jung]

I don't think there should be any mystery as to why the first version of the NWBC was developed in .Net. At the same time that people were blogging about the possibilites of what Muse might be somewhere down the road, there were already people coding on the .Net version of it. It was a simple matter of .Net being a known quantity and readily available and things like AIR were still very much in the early conception phase. You have to remember that these projects get started years before they reach customers. I saw the first running prototypes of NWBC (which was C and .Net based) over 2 years ago.

I think there might be some confusion around "Muse" because there was public discussion about prototypes and visions of the future. Things often change during the prototype phase. It can also take years before prototypes reach the production ready stage.

Even at this point I would hate to comment on where NWBC will definitely be in a few years from now. We still have some internesting prototyping and experimenting going on in this space. For now however, the .Net based version of the NWBC remains our primary delivery of the full Smart Client experience. But the prototyping and exploration that we have already done has validated one important thing - that the architecture that SAP has created around Web Dynpro and xBCML is flexible enough to adapt to many different client technologies. It is no secret that we have xBCML renders for the .Net NWBC implementation as well as for Adobe Flex (already in productive use for Visual Composer's Web Dynpro Output) and Microsoft Silverlight. We will utilize this flexibility of xBCML in the best way possible moving forward.

[Former Member]

The other issue that I witnessed first hand was that the Java stack was not always the most stable environment and difficult to support. I used to work for a company that implemented ESS/MSS and Travel Management on ECC 6.0. Majority of these applications were built on WDJ. There were three major issues that we encountered:

1. The Java stack was going down at least once a week. Before I left, I don't think we ever discovered the true root cause of this. But most likely it was linked to memory usage. Unfortunately the Java side did not clean itself up very well so when we had a high number of users on the system, things went down hill.

2. Patching the Java stack was never easy. I don't think we were ever able to patch the stack without getting SAP involved. Also, it is not quite as easy to correct a single application. In the ABAP world, SAP could deliver OSS notes with small source code changes. On the Java side, it always required a bigger effort to corect a single application. Have you ever seen the number of different "components" and patch levels on the Portal/ESS/MSS side of things?

3. Finding the root cause of issues with the applications split between stacks was always a challenge. In the ABAP world you know that issues are isolated. In a dual stack world where front end is built on Java and backend business logic in ABAP, it always became a problem. Java exceptions are quite difficult to read and finding out which side of the fence your issue was on required more time.

Unfortunately for those companies used to supporting an ABAP based system, these challenges put a bad taste in people's mouths and it makes it harder to sell other cases to use the technology.

Best Regards,

Chris H.

[Former Member]

I think the dual system-environment itself is as well the problem as one side relying on a half-baked technology. A complex application built on top of 2 or even 3 different servers implemented in 2 different languages like ESS/MSS was/still is needs a Java- and an ABAP developer, a Basis guy familiar with the ABAP and one capable of the Java stack, then comes the Portal, which itself again creates at least roles for a Portal developer and technology consultant.

Because the Java stack trace the Portal user receives when clicking on an iViews button could be caused of app errors in ESS Java- or ABAP part, Portal or the connection between these, you as well need an End-to-End Root Cause Analyzer. And this guy must have enough patience to dig through the Java-Application and Portal logs via high-performance web-tools with response times long enough to get you a cup of coffee.

If you want to enhance the whole thing, you' re in the middle of the next technology, the Floor Plan Manager, which again needs SAP training hours and is the next potential cause of error. And if you' re forced to modify the whole app, you need to install the NWDI, which again comes with own roles, security concepts, SPAU techniques a.s.o.

And talking about SPAU/debugging: think of how funny it is to debug a VC app calling a CAF service relying on an ABAP function module - or to modify one of these components.

[markus_doehr2]

> 1. The Java stack was going down at least once a week. Before I left, I don't think we ever discovered the true root cause of this. But most likely it was linked to memory usage. Unfortunately the Java side did not clean itself up very well so when we had a high number of users on the system, things went down hill.

Same is happening here. We have "blank pages" or "Error 500" in a federated portal network and all we can do to get the system up quickly again is to restart all involved instances. We COULD open OSS calls but until they reach the person, who's able to help, there would be DAYS sending the message from component to component. We tried this once with prio-1, I had 3 nights without sleep (due to people working 24 h on the call) and ended in doing exactly what we are doing now - restarting.

> 2. Patching the Java stack was never easy. I don't think we were ever able to patch the stack without getting SAP involved. Also, it is not quite as easy to correct a single application. In the ABAP world, SAP could deliver OSS notes with small source code changes. On the Java side, it always required a bigger effort to corect a single application. Have you ever seen the number of different "components" and patch levels on the Portal/ESS/MSS side of things?

Those things got REALLY better in the past although there is still potential.

If the MOPZ would take the actual patches instead of the "_0-Version" it would be really good

<...>

> Unfortunately for those companies used to supporting an ABAP based system, these challenges put a bad taste in people's mouths and it makes it harder to sell other cases to use the technology.

Yes - full ack and this made us trying to avoid it where it's still possible.

Markus

[Former Member]

> > Unfortunately for those companies used to supporting an ABAP based system, these challenges put a bad taste in people's mouths and it makes it harder to sell other cases to use the technology.
> 
> Yes - full ack and this made us trying to avoid it where it's still possible.
> 

And what does this tell us about the market opportunities of nice so called follow-up technologies that are Java-based like Adobe Forms? Even if the weren' t that expensive in ther Interactive form, nobody want' s to touch the Java stack as long as Smartforms still are supported.

[markus_doehr2]

> And what does this tell us about the market opportunities of nice so called follow-up technologies that are Java-based like Adobe Forms? Even if the weren' t that expensive in ther Interactive form, nobody want' s to touch the Java stack as long as Smartforms still are supported.

We're currently in a rollout project for Russia. Most of the SAP delivered preconfigured forms are implemented using Lifecycle Designer (and believe me, for Russia there are a LOT of them..)

We can either choose to use those (and another J2EE application server) or we could reinvent the wheel - with all the problems that comes, when legal changes apply and which we would get through support packages if we would use "the standard" in that case. We now need to support SAPScript (for lables), Smartforms (for all the other stuff) and SFP.

I still think, those new technologies are really nice and nifty if you start implementing an environment from scratch or if you plan to start a complete new process.

Markus

[Former Member]

At least SAP has done away with the need for the Active Control Framework on the client machines for the Adobe Forms. This was one of the major reasons we decided not to use them during our project. They released the support package to decouple them from the ACF and we were already to far along in our testing to apply any more support packages.

Best Regards,

Chris H.

[matt]

I've used the Adobe lifecycle designer, and found that, compared with sapscript and smartforms, it's a positive joy to use. Sure, it uses the Java stack, but I can use it entirely from ABAP. So what's the problem?

Also, rather tongue in cheek, I've no problem with, especially in BI, ABAP and Java (and Javascript) making me the "must have" for BI projects. Keeps me in work!

I'm not the only, btw - other people with a technical bent in my client environment are doing very well with similar skills.

matt

[markus_doehr2]

> I've used the Adobe lifecycle designer, and found that, compared with sapscript and smartforms, it's a positive joy to use. Sure, it uses the Java stack, but I can use it entirely from ABAP. So what's the problem?

The problem is, that in your case, YOU don't need to manage the Java in the background, you don't have to deal with JDK parameterizations, non-working deployments, non-consistent backups (because you can't really online-backup a Java instance) etc. etc. Sure, from a users perspective it's a nice thing...

> Also, rather tongue in cheek, I've no problem with, especially in BI, ABAP and Java (and Javascript) making me the "must have" for BI projects. Keeps me in work!

Yeah - if you just USE the software - I'm sure.

> I'm not the only, btw - other people with a technical bent in my client environment are doing very well with similar skills.

Of course - but apparently you have no idea about how much effort it costs if you switch from one technology to another.

Markus

[Former Member]

I've used the Adobe lifecycle designer, and found that, compared with sapscript and smartforms, it's a positive joy to use. Sure, it uses the Java stack, but I can use it entirely from ABAP. So what's the problem?

From a development perspective I completely agree. The Adobe forms solution works quite nicely in the backend except for the screen size limitations in Live Cycle designer. The other thing that I have heard mentioned before that helps makes the case for the Adobe forms is that Smarforms are not considered "Accessible". I am not sure how this translates across the world but this gets into technology like screen readers for the visually impaired.

However we had some issues getting the one Adobe form we needed implemented. SAP requires you to use an Adobe Form for output of expenses in Travel Management. (This is the WDJ version and not the WDA version that was recently released). Everything that was developed worked fine from the backend and we could even test it successfully with some programs SAP provides for Travel. As soon as we went to the Portal and the WDJ app, we had some issues. SAP was in the process removing the Active Control Framework from the mix. Unfortunately it was removed from the ABAP stack but not from the Java Stack. To make a long story short, it took quite a bit of back and forth with SAP for them to give us a fix to the travel WDJ application to allow for this form to work with patching the entire Java Stack. And if memory serves me correct, we got the fix through unofficial channels and not OSS.

Again I think things with the interactive forms solution is starting to stabilize and you are seeing it being used more.

Best Regards,

Chris H.

[markus_doehr2]

<...>

> Again I think things with the interactive forms solution is starting to stabilize and you are seeing it being used more.

We were implementing ESS on 4.7 and after our upgrade to ERP we had to go that way too. In the "early days" under 4.7 it was ITS and R/3 - a report was written, executed through ITS as transaction and that was it.

Nowadays we have five involved systems (LDAP, SLD, consumer portal, producer portal, Adobe document service), a dozen Webdynpro and Webservice connections with users, passwords, and roles, SSO certificates, WSRP/RRA, necessary application customizing (infotypes) to basically do the SAME stuff and to output the SAME paper.

If on ANY of those systems/connections/handshaking something is going wrong, it won't work and you really have a hard time finding out, what's the reason because there is nothing "on top of it" that will really help you to manage it. E2E is changing too often/much, setup of that is a nightmare itself and it is still not really able to tell "connection X to Y is not working due to Z".

From the frontend perpective you get more dependencies and more patching of SAPGUI, there exist incompatibilities between certain versions of Acrobat DLLs and Lifecycledesigner DLLs where one of those will work when the other is not. When we added ALD to our SAPGUI installation server it got hosed up...

Don't get me wrong, it's not bashing, it's just the normal utter devastating nightmare of an administrator.

We are using it because we HAVE TO if we plan to implement certain functionality - but I can just appeal: keep it SIMPLE, don't add another framework to another layer on top of a layer on top of a framework. Too much complexity is the dead of each technology.

Markus

[matt]

...
> Of course - but apparently you have no idea about how much effort it costs if you switch from one technology to another.
> 
> 
> 
> Markus

No, I don't understand. What I don't understand is what you mean by "switch". The two technologies run in parallel. And what does the cost matter if it's driven by business requirements? The cost to whom? Would it have been possible/cost effective to implement, e.g. Adobe Forms, without the Java stack.

[Former Member]

Switch form processing from ABAP based Smartforms to Java based Adobe for example. Regarding these 2 technologies SAP didn' t announce a coexistence, but a replacement. And the business requirements for Online/Offline Interactive Forms or Printing via Adobe still have to be proven - in HR, the interactive stuff was not the big hit!

[matt]

Ah, ok.

thanks

[markus_doehr2]

> > Of course - but apparently you have no idea about how much effort it costs if you switch from one technology to another.

> >

> >

> >

>

> No, I don't understand. What I don't understand is what you mean by "switch". The two technologies run in parallel. And what does the cost matter if it's driven by business requirements? The cost to whom?

The costs are:

- form developers need to learn yet-another-tool

- the basis staff has to make sure the additional services (Adobe) is running and working, most probably it needs to be an (another) HA solution if business critical

>Would it have been possible/cost effective to implement, e.g. Adobe Forms, without the Java stack?

Possible - no, cost effective - definitely - if it could run on the same instance on the same for-years-working proven ABAP technology instead of a deficient Java stack. Out of my experience with J2EE each instance needs about 25 - 30 % more resources (speaking of human resources, administration tasks etc.) than a comparable ABAP stack (this was calculated last year).

Markus

[markus_doehr2]

So, to come to the conclusion: What I realized in my work life is that daily business is pretty innovation-resistant and I personally don' t think that even half of all the "emerging technologies" will make it for the next 5 - 10 years.

Yes - it is indeed. If a company invested quite lots of money to get a certain application (or a part of it) working they won´t switch to a different technology just because it´s "hip" at the moment. For new customers it is certainly a very nice alternative to use the new technologies instead of the "old ones".

And to quote the example I said already a few times: If ABAP was so bad, why would SAP themselves switch certain applications back to WD-ABAP (speaking of Travel Management in Enhancement Pack 2 e. g.).

What I also realized is that a lot of time and work has to be spent by developers to keep in touch with new development techniques, which could be used better for clearing white spaces in classical ABAP as well as module programming environments. If developers would focus more on ABAP and module knowledge than on the newest Modelling-techniques many SAP systems probably wouldn' t be spoiled by poor custom developments, enhancements and modifications as they are today!

What I´ve heard the new paradigma is

- Service provisioning: ABAP

- Service consumption: Java

Whatever this means in detail.

I can hardly imagine removing the SAPGUI out of our e. g. sales department and replace it by e. g. a nice "guided procedure" using NWBC. In maybe 5 % of the todays cases this would be enough, the other 95 % still need the full featured transaction with all the tabs, fields and editing functionality.

And what I find the most interesting in that area is: SAP internally I always see SAPGUIs on the (supporters, sales dep.) desks, the "backend OSS/CSN" is still accessed by GUI and not by web, guess why...

Markus

[matt]

I switched from ABAP over to BI in the last few years. With my ABAP knowledge and experience, I still do a lot of programming in BI.

Many parts of BI use the Java stack. Much is web enabled, since access via web is cheaper than via SAPGui and its components. As a result, I work in both ABAP and Java, and have used much of the new technology.

So I guess the use of new technology depends very much on which part of the SAP landscape you are working on, the version installed, and the requirements of the business. Also whether the new tech. has been implemented via third parties before SAP were ready with their offering.

matt

[Former Member]

But what for? I mean, what' s the big advantage of a Java-based new service consumption layer in every day business? No direct access to lots of great ABAP features like DDIC-help, no enhancements, a 2nd IDE to learn, a 2nd landscape to handle, problems in debugging and performance. Why has SAP spent so much efforts in building a parallel world instead of improving the real one?

[Former Member]

BI is a good example as it previously was a clean ABAP installation and now is a split application. I don' t think that there are comprehensible reasons for implementing the web parts as Java apps instead of keeping them in the ABAP system as WDA.

But probably SAP has once again to go the rocky road with a first implementation in Java, refusal by customers and the the switch back to ABAP.

And this is what I criticise the most: All the functional and development efforts could have been spent in a stable ABAP version from the beginning instead of implementing the same things again and again in Java and ABAP.

[markus_doehr2]

> Many parts of BI use the Java stack. Much is web enabled, since access via web is cheaper than via SAPGui and its components. As a result, I work in both ABAP and Java, and have used much of the new technology.

Cheaper? No.

Given the amount of "special configurations" you need to do in the browser it's even worse from an administrative point of view - speaking of security zone configuration, proxy exception lists, certificates, security patches, non-working Kerberos/AD-integrations with the new JDKs.... and many of those things needs to be done per PC AND per user. On top of that, you're totally bound to Microsoft Internet Explorer (try to use BEx-Web with Firefox or Opera or on Non-Microsoft machines).

All presentations of "fire up a browser and go" are just that - presentations and wishful thinking - if you don't live in a Microsoft-only world.

Just my EUR 0.02

Markus

[markus_doehr2]

> But what for? I mean, what' s the big advantage of a Java-based new service consumption layer in every day business? No direct access to lots of great ABAP features like DDIC-help, no enhancements, a 2nd IDE to learn, a 2nd landscape to handle, problems in debugging and performance. Why has SAP spent so much efforts in building a parallel world instead of improving the real one?

Because "the market" requested it (where "the market" could be the ERP market, analysts, big customers or just the fact, that the biggest competitor had SOA/ESB/insert-buzzword enabled products - even when they exist(ed) only on powerpoints - and was AGGRESSIVELY advertising with that).

SAP was told to rely on ancient technology ("COBOL like language") and being completely proprietary without any real open interfaces but their (also proprietary) RFC. Java was the next logical step - which is fine, as long as it is OPTIONAL and not REQUIRED. I'm still happy Java was chosen over .NET - imagine...

Driving and running a Java instance costs about 27 - 30 % more per instance than ABAP - speaking of TCO, so the nice(r) (?) user interface is payed much with more resources to handle it. Some of those applications do look really better and nicer than dynpro screens - admittedly - but is that really worth it? The bad thing - the customers have no choice if they want to run certain applications...

Markus

[Former Member]

That' s an answer I heared and read quite often. ABAP development came in a dead end street, ABAP developers were too expensive and Java brought in the winds of change.

But you know what: ABAP speaks HTTP, SMTP, SOAP, XML, JavaScript, its object oriented extension, a comprehensive class library, a modern web ui and still its mighty proprietary features like Open SQL and the fast RFC.

So let' s for a minute presume that all major language and IDE improvements in ABAP are a result of the Java competitor: the pursuit race has now come to an end. No further need for the underdog but to keep it for downward compatibility.

SAP should also build it' s service consumption layer on a proven, established and widely accepted technology instead of continuing the Java experiment on their customers expense.

[Former Member]

Thomas,

I think SAP has come a long way with their ABAP Web UI, however I still don't know if I would consider it a modern web UI. WDA is really meant for presenting business transactions over the web and still looks and feels a lot like SAP. BSPs give you the ability to get away from the SAP look and feel but are cumbersome to develop.

I think that SAP has already laid the groundwork to move your consumption off of the Java track if you would like. For instance if you expose all your services in the ABAP back end, I believe you could create an Adobe Flex applications without any Java stack at all. The next step would be to remove the portal and all standard WDJ applications from the mix. They are already moving a lot of the WDJ applications back to WDA but I don't know if you would ever get a portal that ran without the J2EE engine. And then all we need is a composition environment on the ABAP stack. Then ABAP can take over the world and put this argument to rest already.

Best Regards,

Chris

[markus_doehr2]

> SAP should also build it' s service consumption layer on a proven, established and widely accepted technology instead of continuing the Java experiment on their customers expense.

I believe there is no way back.

And a "widely accepted technology" would be more likely Java (or .NET) than ABAP. J2EE IS a standard (and not only a de-facto one) although I still doubt, that it's possible, to build a really rock solid big application on top of J2EE.

I think the new Netweaver (or whatever it is called then), which includes SAPs own JDK will help a lot here, I'm very sure, they learned their lesson too and that the development department is having hot brains how to deal with all those deficiencies in the future. It will take some time though - and until then we have to manage and deal somehow with "that mess".

And yes - I agree, maybe Java was some sort of catalyst for the ABAP development (such as "we can do too!") so all that had a positive side - and if it was only that

Markus

[Former Member]

BSPs give you the ability to get away from the SAP look and feel but are cumbersome to develop.

BSP = Before Screen Painter 😛