JCO und Developer Studio

Re: JCO und Developer Studio

Hallo Frank,
hilfreich könnte das folgende Tutorial sein:
http://www.abapforum.com/forum/viewtopic.php?t=1962

wie auch die PDF Session von Brockhaus:
http://www.abapforum.com/forum/viewtopic.php?t=2092

Für den Einstieg noch ein paar Beispielprogramme:
http://help.sap.com/saphelp_nw04/Helpda ... ontent.htm

Meines wissens nach ist der JCo kostenlos und entsprechend über den Marktplatz verfügbar & ja, ich habe mit Eclipse dagegen programmiert.

Gruß Aze

Re: JCO und Developer Studio

his is an old article, written back in 2006 but never published. I think it's still worth reading and beside the fact, that oracle now took over bea, and some product versions moved on, its still up-to-date.

Today, hardly a single company can do without systems from the SAP AG [1]. SAP – For years, these three letters have stood for business applications and effective company processes. However, despite the wide distribution, there are still not enough classic developers, who feel comfortable enough in the SAP world, that they are able to restore earlier integration solutions. The need for communication between the worlds is becoming increasingly important, which means that it is time to take a look at the different possibilities available and to find ways to support the interaction between the two worlds.

Introdcution


When speaking to developers from a wide range of backgrounds about the issue of SAP, a wide variety of reactions is seen. Whether excited head-nodding or open rejection of the ABAP, BAPIs, IDocs, etc. not a single expression is lacking. The majority of the developer community is not dissatisfied to consider SAP a blackbox and to merely investigate how to get around it.
It is not a surprise that non-SAP developer communities have a difficult time with the topic. There is hardly a range of products that has the same exposure and has still been able to remain so intransparent. Especially the technical aspects of the SAP products are still mostly handled by a select group of specialitists. However, this fact alone does not discourage companies from installing products from the wide range of wonderful and clever abbreviations, such as SD (Sales & Distribution), FI (Finance), CO (Controlling), HR (Human Resources), etc. The main reason though is the increasing cost pressure. The desire to omptimize relevant business processes using standard products and to uniformly support them through the IT usually gets IT departments moving. Yet, this approach is completely comprehensible. If optimization and standardization can save costs, further costs can be saved by employing certified employees instead of training existing employees, and the guaranteed support from the manaufacturer is also an added bonus.
What is quickly forgotten is the fact that such problem-free packages do have their price. In addition to implementation and company-specific customizing, there are also considerable license fees. But these are only a few reasons why companies are tending to portray only the business-critical basics in their standard products (financial accounting, human resource management, etc.). IT usually takes care of the remaining processes using older individual developments, which have expanded over the years and which take some getting used to. These are usually based on Java, Microsoft or other platforms. What initially looks like a feasible interaction actually creates a lot of questions upon closer examination. Many individual developments could potentially use interfaces to SAP, since they can access the same dataset or even functions portrayed in SAP. Thus, it would be rather profitable to connect SAP to the rest of the world.



Developers and Consultants

This is where the history of SAP software in companies becomes interesting for non-SAP developers as well. Both partners would have to sit down and find solutions for questions such as integration, access and data exchange. However, both sides do tend to exaggerate in the reports from such discussions. What is sure, is that it does not usually take long until this babylonian language deficit has prevented any effective cooperation at all.

When taking a close look at a customer’s different views of software, their development processes or related implementation modules, it can clearly be seen that the SAP products do differ greatly from products made by other manufacturers. To put it another way, SAP’s product portfolio contains large blocks of products for optimizing and standardizing almost all company processes. Starting with cross-industry topics, such as human resource management and financial accounting to specific solutions for say health care or the automobile industry…almost every industry is represented. Unlike other products, where programmers work with a program until it fits, no programming is performed in the SAP product. Instead, adjustments are made until the product fits the company processes and situation. This adjustment process is not referred to as “development”, but as “customizing”, i.e. customer-specific adjustments. Which is why it is also important that qualified and certified consultants make the adjustments and not developers.

Consultants speak the language of their product and process. This seems to contradict the work of classic developers, who focus on interfaces, programming languages and process environments. This is a classic process verses technology vocabulary. What makes it even more difficult is that SAP’s varied technology uses its own methods. Although consultants speak about technology as well, they are usually referring to proprietary technologies. With so many differences, it is not surprising that initiating a successful interaction does indeed require some work.
Commonalities


Since the fundamental aspects seem to differ so greatly, it is no wonder that the two worlds do not seem to migrate toward each other and that one world does not know much about the other. To create successful integration solutions between SAP and the rest of the work, a step will first have to be taken in the other direction. Many developers are aware of the abbreviation R/3. R/3 is a company information system (also referred to as ERP - Enterprise Resource Planning). R/3 has been used since about 1993 and is a client/server system. The R stands for realtime and the 3 refers to the 3 layers which create such a system (a database layer, application layer and presentation layer). R/2, the previous version, was designed for operation in mainframe systems. The direct successor of R/3 is mySAP ERP. NetWeaver was presented as the successor at the beginning of 2003. With the R/3 systems, data is stored in standard relational databases, yet the overall business processing is done in an application server. The application server executes the programs written in the proprietary language, called ABAP. Quite an expansion was seen in release 4.7 of the SAP R/3 Enterprise. As SAP’s official answer to the boom in internet technologies, it was named the SAP Web Application Server (WebAS) in the summer of 2000. Event the initial versions, 6.10 and 6.20, already had their own HTTP and Web service interfaces for the ABAP runtime. A parallel Enterprise Java Runtime appeared in the application server in version 6.30 after SAP took over the In-Q-My company. This part of the application is J2EE 1.3 conform and enables Enterprise Java programming. Whereas the technical platform used to be somewhat neglected, it was now receiving increased attention in the SAP product portfolio. The current WebAS 6.40 is the basic process environment for almost all SAP products and is delivered with NetWeaver 2004. Whoever signs up on SAP’s [2] free developer site is also given the opportunity to download and try a few preview versions of the technical basis. In addition to the current NetWeaver 2004 SP16 version, it also provides the successor version NetWeaver 2004s SP7 and a preview of NewWeaer 2007, with limited functionalities.
_________________________________________________________
wasserbetten
Texas >>SPAM<< Predators