connection to SAP
Isaac Welliam
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
Bill Todd [TeamB]
answer is yes.
--
Bill Todd (TeamB)
Ronald Klitsche
> 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
Jean-Noël Voirol
Keith Latham
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.
Isaac Welliam
> If the SAP API is accessed by importing functions in DLLs then the
> answer is yes.
>
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
Isaac Welliam
Isaac Welliam
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.
Isaac Welliam
becasue there is alot of expression I dont understand !!
but Thanks so much for taking all this time to write for me
Isaac Welliam
> https://www.gs-soft.com/confluence/display/SAPx/Connect+for+SAP+Home
>
>
> Jean-Noël
thanks alot I will check this out
Keith Latham
>>
> 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
Isaac Welliam
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