Skip to Content

Brief overview on SAP Interfacing and how does it actually work

SAP system interacts with several other legacy systems (sending and receiving systems) through various middleware tools like XFB, UNIX, Dataware, and EAI.

One best example is the client SAP system interacting with the Banks for sending and receiving payments, bank statements updation etc. SAP receives files / data from the external system here in this case the Bank through XFB and the files are stored in the SAP In directory. The SAP file storage directory can be checked through the Transaction code AL11. All the data coming into SAP and going out of SAP are stored and can be traced in the SAP directory. To differentiate, all the files / data going out of SAP are stored in one particular directory and all the files / data coming into SAP are stored in a particular directory.

File processing – The files are processed into SAP via an automatic job scheduling. Jobs are created for specific programs (could be a standard program or a customized program) to process / integrate the incoming files. The job will pick the file based on the parameters maintained and process the files. If there exists any error during the file processing either due to format issue or amounts mismatch etc., the third party system team has to be approached to send a correct file.  There are specific programs created (standard or customized) to send data out of SAP for which the jobs are scheduled.

Flat files upload in SAP – CG3Z is the SAP standard transaction code for file upload into SAP. We have the option of copying files from the Front end system into SAP via this code. You can specify either ASC or BIN for transfer format for the data.  

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Vijay Vijayasankar
    This blog did make me nostalgic – remembering how we used to do things many years ago as SAP techies. I assume that was the intention of this blog – because otherwise I cannot imagine some one doing this in 2011. I would also like to suggest that you spend some time reading the good blogs on this important area, and try running your draft blog by an experienced blogger to get suggestions for improvement.

    In its current form, this blog does not hold up to the standards I expect from content in SDN. But then we all have to start somewhere, and I am sure you will prepare better for next attempt.

    Good luck

    (0) 
  2. Michelle Crapo
    In a WIKI different experts can comment and change what you have written.  “How tos” are so hard to write.  There are a million of different ways to do things.

    This may help someone who supports an older system.   However, if they are developing something new – it could mislead them.

    It always helps to have comments.  I’ve found that by writting blogs, I’ve learned a lot.  WIKIs even more as people can easily change and make them better!

    I’m sure you’ve learned a lot just by reading these comments.

    Don’t stop blogging.  But a great suggestion is to do a search on SCN to find out as much information as you can prior to writing something. 

    Another thought – the story behind the blog would have been interesting to read.  What were you doing when you stumbled upon this information?   What project?  Did you find it hard to use SCN?  Hard to find the information you needed?    In that case – write about it!  It would be a fun way to see what people would reply.  Instead of a “how-to”, write this is what I did.  This is the project I was working one.  And here’s how I found it.

    I know – long comment.  But have fun.  Don’t worry about all of our comments TOO much.  And don’t let this stop you.  Keep blogging.  Just think about different ways you could do it.

    Loved this blog – try taking a look at it.
    St. David Slays the Wiki-Weblog Dragon

    Michelle

    (0) 

Leave a Reply