ABAP (Advanced Business Application Programming) is a high level programming language created by the German software company SAP. It is currently positioned, alongside the more recently introduced Java, as the language for programming SAP's Web Application Server, part of its NetWeaver platform for building business applications. Its syntax is somewhat similar to COBOL.
History
ABAP is one of the many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting. ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report preparation processor", but was later renamed to c. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level.
The ABAP programming language was originally used by developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.
ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP's applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.
SAP's most recent development platform, NetWeaver, supports both ABAP and Java.
Saturday, February 23, 2008
What is ABAP?
Tuesday, February 19, 2008
What is Mini SAP?
MINISAP is a full-fledged Basis SAP system without the SAP applications (FI, CO, MM, SD, etc.). It has every Basis function of a standard SAP-R/3 system (ABAP/4 Development Workbench, Data Transfer Workbench, Computer Center Management System - CCMS, etc.) and, therefore, is a very good means to get exposed and trained in ABAP/4 programming language.
It is also a very good personal productivity tool (i.e., it can be used to develop programs for customers without having to be on-site).
The minisap are for those who are new and want to get Basis exposure or want to learn ABAP programming at their home PC.
Sunday, February 3, 2008
SAP vs Oracle
It used to be that the ERP market had an 800-lb gorilla, SAP, and a number of smaller competitors. Then Oracle went on a shopping spree, gobbling up companies like J.D. Edwards, PeopleSoft, Siebel, Retek and others. Suddenly, there are two gorillas in the market, along with a whole bunch of customers who now find themselves under the Oracle umbrella. Is this a good thing or a bad thing? So far, customers have been courted by sales reps from both sides and often benefited from having aggressive reps compete over who can offer up the sweetest deal for going all-SAP or all-Oracle.
But the larger issue is: what does the future hold for the ERP market? What good is a bargain today if you have to jump ship again in a few years? More specifically, is Oracle's vision of Project Fusion a pie in sky dream that will only lead to disaster for customers? Or perhaps SAP should be more concerned about issues like TCO and flexibility than they appear to be?
You be the judge -- here are two columns from prominent experts in their respective fields making the case for SAP vs. Oracle. These columns are posted simultaneously on SearchSAP.com and SearchOracle.com, and we invite you to send in your comments. Did the authors miss something? Do you have something to add? If you're a former SAP customer who decided to go all-Oracle, we want to know why, and vice-versa.
NetWeaver Vs. Fusion: Survival of fittest favors the fit
By Faun deHenry
The NetWeaver vs. Fusion competition looks more and more like a Darwinian race for survival, with two distinct but similar species competing for resources in the same biological niche. That niche, of course, is your IT budget, and the race for survival is manifesting itself in briefings and sales presentations across the globe.
The natural world has several strategies for how such a race is run – and won – and each provides some insight into what the eventual outcome of the NetWeaver vs. Fusion struggle will be. One such strategy is competitive coexistence, though at the price of constant conflict. Another biological model is parasitism. A third, the least likely, is symbiosis. But the most probable outcome, the one that everyone at SAP and Oracle would prefer over any other, is the one that nature seems to favor more often than not: total dominance. And, based on what we now know about the two companies' strategies, given such an outcome, NetWeaver would be the winner, hands down.
Why I believe NetWeaver would win out is based on no small amount of digging into the two companies' plans. SAP has been plugging away at its NetWeaver strategy for several years now, while Oracle recently updated analysts, the press, and some customers at a conference in San Francisco. And while there are details and plans galore on both sides (ad infinitum, if not ad nauseam), there are three irrefutable facts that give NetWeaver a serious edge over Fusion.
Better roadmap
The first is that I believe SAP has done a better job of both articulating its roadmap for NetWeaver and delivering on it. To be fair, that is in part because they have been at it longer than Oracle. Remember, Fusion is barely a year old, whereas NetWeaver has been bandied about as a concept for almost three years. But I also believe that SAP's advantage in building out its own applications – as opposed Oracle's strategy of acquiring or partnering to build its applications portfolio – has allowed the market to see more clearly where SAP is going and what functionality will be available once the full force of NetWeaver's service architecture can be brought to bear on the market. Oracle's Fusion Middleware strategy is relatively well thought-out and well-defined, but the roadmap for Fusion Applications still has a lot of blank space in it – placeholders for as-yet unannounced acquisitions and partnerships.
Vertical functionality
This brings me to my second point. In my opinion, vertical industry-specific functionality is where the rubber hits the road as the future of enterprise applications unfolds. Indeed, all that trouble to build and implement service architectures like NetWeaver and Fusion would largely be for naught if all they did was enable more monolithic, general-purpose enterprise software. The real value-add for service architectures comes from their ability to take individual services and build them, Lego-like, into applications that are essentially mass-customized for individual business in individual industries.
This means that, in addition to a strong services infrastructure, a vendor needs a large portfolio of services to assemble – the more the merrier. This is where SAP's next advantage comes into play. SAP's has experience in 28 verticals, and the software functionality to prove it. As NetWeaver unfolds, one of SAP's tasks will be to service-orient all that functionality and make it available as building blocks for the future. That's a non-trivial task, but one that, once done, provides SAP customers with an exceptionally large palette of vertical industry functionality on which to build their service-oriented future.
Oracle, on the other hand, has always lagged in providing deep vertical functionality, a fact acknowledged by the vertical focus of their acquisition and partnering strategy. While there is some deep vertical functionality now in the Fusion playbook – Retek in retail was a major coup, and Siebel can provide some CRM-specific vertical functionality in the industries that it targeted – the scope of this functionality still lags behind that of SAP. And while Oracle is now vowing to fill in the blanks with more partner products, until we can evaluate exactly what those products can do and how many vertical industries they allow Oracle to compete in, SAP still has the vertical industry advantage.
The Fusion timeline
Finally, I have trouble with Oracle's very ambitious timeline for its Fusion Applications. Oracle argues that they are "halfway to Fusion", largely on the strength of their work on Fusion Middleware. I'll grant them that. But halfway to Fusion Applications – particular a suite of highly verticalized service-oriented applications based on least six different code bases (if you count the pieces of software that make up its Oracle, PeopleSoft, J.D. Edwards, Siebel, Retek, and ProfitLogic product lines) – I'm having trouble with the scope of that task. Bear in mind, Fusion Applications are slated to come out in 2008, after Oracle releases updates to its eBusiness Suite, PeopleSoft, and J.D. Edwards lines. That is, to use a technical term, a boatload of application development work.
Sure Oracle is big, sure they're full of some of the smartest minds in the industry… so is Microsoft, whose ambitious plans to develop its own next-generation version of its enterprise software suite – Project Green – foundered and has been radically redrawn and retimed. (Not to mention Microsoft's plans for its operating system, middleware, and a fair amount of the rest of its offerings.) In other words, history tells us that that huge software projects at a minimum tend to miss their deadlines, if not fail hugely. And while I don't think Oracle will fail – Fusion Applications will some day see the light of day – I don't believe that day will dawn in 2008.
Again, to be fair, SAP also has a monumental development task – but it's from a single code-base of software that the company has spent 20-plus years developing. NetWeaver's timetable benefits greatly from its status as a next-generation project based on internally developed software, and not on a massive blending and rewriting of a half-dozen different applications and code-bases.
In the end, software evolution plays by different rules than biological evolution, and Fusion's prospects could change quickly in the next year or so. But, as things stand today, Fusion looks like a candidate for endangered species protection, even before it actually enters the race for survival. If biology defines software destiny, Fusion's destiny looks perilous at best.
Joshua Greenbaum, Market Research Analyst & Consultant, Enterprise Applications Consulting
Joshua has more than 15 years of experience in the industry as a computer programmer, systems analyst, author, and consultant. Prior to starting his own firm, Enterprise Applications Consulting, he was the founding director of the Packaged Software Strategies Service for Hurwitz Group, which focused on technology, infrastructure and business issues in the enterprise applications market.
Source: SearchCRM
Related Links:
