🚀 go-pugleaf

If the SAP API is accessed by importing functions in DLLs then the
answer is yes.

-- 
Bill Todd (TeamB)

> I saw a programming language called WinDev can do that by login to the SAP 
> system and import the desired functions which give me a direct way to call 
> those function, is there a way to do the same with Delphi ?

Do you mean to create dynamic RFC function in SAP during "runtime"?
If yes, you have to create a RFC function in SAP to do that in ABAP.
You can call that RFC function from Delphi with the "new ABAP coding" as a 
parameter and the
function will generate an new RFC function callable from Delphi. ... evil.

For security reasons I assume that no company will have that functionality 
in their systems;-)

Ciao
Ronald

https://www.gs-soft.com/confluence/display/SAPx/Connect+for+SAP+Home


Jean-No�l

Isaac Welliam wrote:
> I need to build a win32 application that connect to SAP ARP System and 
> get data from that system directly with the need to modify SAP to make a 
> special export module
> 
> I saw a programming language called WinDev can do that by login to the 
> SAP system and import the desired functions which give me a direct way 
> to call those function, is there a way to do the same with Delphi ?
> 
> Thanks

It isn't too difficult, but does take a bit of study. I have built (over 
5 years ago) several different Delphi-SAP links. One was a performance 
monitor as a learning exercise, no updating of SAP was required. Another 
was a Password changer for external helpdesks where they didn't want to 
expose the SAPGUI. For that I had to write code on both sides, the 
Delphi front-end and the ABAP code to change the passwords and log the 
changes, etc.

Both these systems used the SAP RFC calls via the SAP supplied DLL's. 
This technique enabled communication with SAP via screen-scraping 
existing screens or invoking BAPI's. If the functionality you want is 
not exposed on a user screen (that can change from release to release, 
or by configuration) or a provided BAPI, you will need to write your own 
BAPI (or have it written for you of course).

In a Windows environment, these things all reduce to a RPC using DCOM I 
guess. You basically just have to know how to marshall the parameters 
into the correct parameter block and send it down the wire using the 
appropriate DLL calls. As I recall, I had a bit of trouble with passing 
array parameters to SAP, but I didn't have any trouble reading array 
replies.

For security purposes, I organised a user ID that could not be logged on 
via a GUI; that is, it was what SAP used to call a CPI-C only user. The 
terminology has changed and CPI-C has nothing to do with it anymore, but 
I can't remember what it is called in NetWeaver. This stuff is pretty 
much obsolete anyway.

Since my efforts, SAP has put in place a lot of web services, so by now 
you should be able to do just about anything you need to do with, for 
example, SOAP messages or whatever new XML based messaging tool they 
have in place now to invoke BAPI's.

To deliver your message and SAP's response, there are several messaging 
interface tools which would really be the correct way to go here. SAP 
Process Integration (SAP PI) (formerly called SAP Exchange 
Infrastructure or just XI) is built-in to SAP and is probably what you 
would want to use. Or your client may have IBM's messaging or one of 
several other 3rd products. That's really the best place to start 
looking. Or you can use the product Jean-No�l has pointed you to (I have 
not used it - don't know anything about it).

Whatever you do, don't think you can just read the SAP database and 
update it and avoid the SAP overhead, unless you or your client has 
developed the entire SAP based application from the ground up and have 
complete control over it. On reflection don't even do it then or you 
will be in extreme difficulty when they change something under the covers.

YOU *MUST* INVOKE THE SAP BUSINESS LOGIC OR YOU *WILL* CORRUPT YOUR 
CLIENT'S DATABASE.

SAP does have a 'free' learners version you can download from their site 
  for learning SAP ABAP, or SAP Java. These learning platforms do not 
have the SAP ERP application or any other application beyond their 
training systems, so you would need to set up your own stuff to test 
with. I haven't tried to see if I can connect to them remotely (by that 
I mean over the 'CPI-C' connection as opposed to SAPGUI or Browser) or 
not. I suppose you can, but I think printing is disabled, so maybe 
remote connection is too. They have a 90 license that you can renew 
indefinitely.

Bill Todd [TeamB] wrote:
> If the SAP API is accessed by importing functions in DLLs then the
> answer is yes.
> 
sorry for my late reply, do you hear about windev ? (http://www.windev.com)

In this url http://www.windev.com/pcsoft/videos.html#liste a technical 
video called "Native access to SAP" on how windev can connect to sap API 
(like you said) but I have no idea how to do the same in Delphi, is like 
calling a function inside a DLL ?

Thanks

I have no control on SAP system at all

also if there is no documentation or help from SAP can I still be able 
to do that ? for example browsing all SAP functions and choose what I need

This like hacking into SAP system because developer of this system will 
not help me in any way, but an owner need me to get data from SAP black box.

Jean-No�l Voirol wrote:
> https://www.gs-soft.com/confluence/display/SAPx/Connect+for+SAP+Home
> 
> 
> Jean-No�l
thanks alot I will check this out

Keith Latham wrote:
> Isaac Welliam wrote:
>> I need to build a win32 application that connect to SAP ARP System and 
>> get data from that system directly with the need to modify SAP to make 
>> a special export module
>>
>> I saw a programming language called WinDev can do that by login to the 
>> SAP system and import the desired functions which give me a direct way 
>> to call those function, is there a way to do the same with Delphi ?
>>
>> Thanks
> 
> It isn't too difficult, but does take a bit of study. I have built (over 
> 5 years ago) several different Delphi-SAP links. One was a performance 
> monitor as a learning exercise, no updating of SAP was required. Another 
> was a Password changer for external helpdesks where they didn't want to 
> expose the SAPGUI. For that I had to write code on both sides, the 
> Delphi front-end and the ABAP code to change the passwords and log the 
> changes, etc.
> 
> Both these systems used the SAP RFC calls via the SAP supplied DLL's. 
> This technique enabled communication with SAP via screen-scraping 
> existing screens or invoking BAPI's. If the functionality you want is 
> not exposed on a user screen (that can change from release to release, 
> or by configuration) or a provided BAPI, you will need to write your own 
> BAPI (or have it written for you of course).
> 
> In a Windows environment, these things all reduce to a RPC using DCOM I 
> guess. You basically just have to know how to marshall the parameters 
> into the correct parameter block and send it down the wire using the 
> appropriate DLL calls. As I recall, I had a bit of trouble with passing 
> array parameters to SAP, but I didn't have any trouble reading array 
> replies.
> 
> For security purposes, I organised a user ID that could not be logged on 
> via a GUI; that is, it was what SAP used to call a CPI-C only user. The 
> terminology has changed and CPI-C has nothing to do with it anymore, but 
> I can't remember what it is called in NetWeaver. This stuff is pretty 
> much obsolete anyway.
> 
> Since my efforts, SAP has put in place a lot of web services, so by now 
> you should be able to do just about anything you need to do with, for 
> example, SOAP messages or whatever new XML based messaging tool they 
> have in place now to invoke BAPI's.
> 
> To deliver your message and SAP's response, there are several messaging 
> interface tools which would really be the correct way to go here. SAP 
> Process Integration (SAP PI) (formerly called SAP Exchange 
> Infrastructure or just XI) is built-in to SAP and is probably what you 
> would want to use. Or your client may have IBM's messaging or one of 
> several other 3rd products. That's really the best place to start 
> looking. Or you can use the product Jean-No�l has pointed you to (I have 
> not used it - don't know anything about it).
> 
> Whatever you do, don't think you can just read the SAP database and 
> update it and avoid the SAP overhead, unless you or your client has 
> developed the entire SAP based application from the ground up and have 
> complete control over it. On reflection don't even do it then or you 
> will be in extreme difficulty when they change something under the covers.
> 
> YOU *MUST* INVOKE THE SAP BUSINESS LOGIC OR YOU *WILL* CORRUPT YOUR 
> CLIENT'S DATABASE.
> 
> SAP does have a 'free' learners version you can download from their site 
>  for learning SAP ABAP, or SAP Java. These learning platforms do not 
> have the SAP ERP application or any other application beyond their 
> training systems, so you would need to set up your own stuff to test 
> with. I haven't tried to see if I can connect to them remotely (by that 
> I mean over the 'CPI-C' connection as opposed to SAPGUI or Browser) or 
> not. I suppose you can, but I think printing is disabled, so maybe 
> remote connection is too. They have a 90 license that you can renew 
> indefinitely.
> 
> 
Wow I need to read you message again with clear mind before I reply 
becasue there is alot of expression I dont understand !!
but Thanks so much for taking all this time to write for me

Isaac Welliam wrote:
>>
> Wow I need to read you message again with clear mind before I reply 
> becasue there is alot of expression I dont understand !!
> but Thanks so much for taking all this time to write for me

The bottom line is that you NEED a SAP interface expert to help you.

SAP is NOT a database system, you can't just connect to it and 
manipulate its data. It is an application system and you have to play by 
its rules. There are over 8000 tables in the SAP ERP application and the 
business logic that ties those tables together is enormous. If you muck 
it up you will not be popular. As long as you play by the rules you are 
pretty safe.

The major rule that you have to play in your case is that there are 
three ways to interface with SAP from a non-SAP program (Not counting 
'traditional batch files') :

Method 1) Use the SAPSDK (System Development Kit) dll to issue what SAP 
calls RFC's (Remote Function Call). This method is 'old-fashioned' and 
probably should not be used anymore. It allows you to interact with SAP 
in two ways:

a) Invoke an SAP transaction and set or access (screen-fill or 
screen-scrape) the fields on the screen. This is a dangerous method, 
because screen layouts can change from release to release, and even by 
local installation configuration.

Example: you need an invoice (this is just an example off my head and is 
not necessarily indicative of the exact transaction):
Step 1. Log on to SAP (dll call).
Step 2. Build a parameter list that fills the required query details 
onto the SAP Display Invoice Transaction (I can't remember the 
transaction ID - it has changed at least three times since I have been 
working with SAP - and I don't work with it anymore). The bad news is 
that these parameters are complicated and difficult. The good news is 
that SAP has a utility program to cut Visual Basic code for a specified 
screen. You just need to translate it to Delphi. Good luck.
Step 3. Invoke the SAP Display Invoice Transaction with the query screen 
you built in Step 3 (dll call).
Step 4. Receive the reply and if not an error get the details you need 
from the Invoice Header Screen (this is screen-scraping).
Step 5. Build a parameter list that tells SAP to change to the Invoice 
Detail Screen.
Step 6. Send the request to SAP (dll call).
Step 7. Receive the reply and if not an error get the invoice details 
you need from the Invoice Header Screen.
Step 8. If you need other information, for example, Customer Details or 
Stock Item details, do this all again for the corresponding Display 
transactions.
Step 9. This method is extremely sensitive to any change in the 
transactions.

b) Invoke an SAP RFC enabled function with parameters. SAP functions are 
written in ABAP, and enabling them for RFC is a matter of setting a 
switch in their definition. SAP supplies hundreds of functions and 
installations can and do write their own. If the function you need is 
supplied by SAP but is not RFC enabled you have to write a wrap it in a 
local function to turn on the RFC. If the function you need does not 
exist you need to write your own.

Example:
Step 1: set up a parameter list for the "get invoice header" function 
(can't remember its exact name). This parameter list is much easier to 
set up than the one above. I have not found a way to automate this for 
Delphi. This is the short-cuts that products like "WinDev" or the old 
"Borland Delphi for SAP" product do for you I think.
Step 2: invoke the function (dll call).
Step 3: receive the reply into your specified buffer. Now you need to 
get the data you are interested in out of the returned parameter buffer. 
Again its code and you need to be able to compute offsets and such.
Step 4: repeat the process for the "get invoice detail" function.
Step 5: repeat the process for any other data you need.

Method 2) Invoke an SAP BAPI (Business Application Programming 
Interface). This is the modern approved method. Form your point of view, 
a BAPI is simply an RFC enabled function as in 1b above, but it tends to 
package stuff into Business Objects. There are again two processes possible:

a) Invoke the BAPI as you did the 'normal' RFC call:

Step 1. Set up a parameter list for the "BAPI_GET_INVOICE" (or whatever 
it is called) as above. You can specify what data should be returned.
Step 2. Invoke the function (dllcall)
Step 3. receive the reply and extract your data. This time all the data 
relating to the invoice should be included in the reply (if you asked 
for it), including Header, Detail, Customer, Stock, etc.
Step 4. You are done.

b) Invoke the BAPI via XML. This makes most sense to me as being the 
most straight forward (notice the progression of hard to easy in the 
processes I have listed - this has occured over 15 years). I haven't 
used this method so I am most vague on this.

Step 1. Set up an XML request to invoke the BAPI (in a SOAP envelope I 
guess?).
Step 2. Send the XML request to SAP. (using SAP Process Integration?)
Step 3. Receive the XML reply (parse the response using whatever you 
like to extract your data.

Method 3) Use SAP IDOCs (Intermediate Documents). I forgot about this 
one the other day. An IDOC is a formatted data record (the format must 
be defined inside SAP as a 'message type') which can be delivered to SAP 
for processing either via a 'real time' message or as part of a 
'traditional batch file'. IDOCs invoke BAPI's, function modules, or ABAP 
programs to process transactional data. They are especially useful for 
Business-to-Business communication, and actually provide the framework 
for SAP's EDI support. There is a very robust status tracking and 
recovery mechanism. If you are using this method, is is possible that 
you are just creating another source for an existing IDOC process - 
perhaps you are submitting work orders from one department to another, 
or purchase orders from your client to an external supplier. This would 
be almost trivial to implement as the 'message type' would already be 
defined and you just have to build examples of the message and deliver 
them to the right IP address using the right protocol.

Whatever you do, it will require close cooperation with your 
installation's SAP people: Netweaver administration, Security, and ABAP 
Development. You may very well have a separate Interface team as well. I 
strongly suggest you make contact with these people and develop a good 
relationship no matter what method you use.

You boss should help you with this if you don't already have the 
appropriate contacts. In fact, you should have gone to talk to them 
first, even before you asked here. It is unlikely that you are the first 
one that needs to interface with your SAP installation, and they 
probably have a bit of experience with it and local standards and 
methodologies that you will need to be aware of. They can probably steer 
you to XML or IDOC or whatever fits your requirement the best.

Especially if you need to use the SDK, there will almost certainly be a 
learning curve on their side as well as yours. But nothing can be done 
with out the SAP team's cooperation. The worst thing you can do is to 
try developing this thing in isolation and then spring it on them. Get 
your SAP installation team involved early and get them onside.


Good Luck

Thanks alot Keith Latham your help is much appreciated, I will try to 
contact the SAP development team but I dont know if developing this 
application will require from me to travel to the client country and 
stay for months until the project is finished this would be add alot of 
cost.

also what do you think about the component "connect for SAP" ? is it 
good and can minimize cost, time and effort ?

If possible please send me your contact info to isaac_cm<at>yahoo.com if 
you dont mind my company would need your services when we start in this 
project we still now in study phase.

Thanks again
My Regards
Isaac