DS 3.2 u201CDirect Downloadu201D from SAP ECC Dump RFC_ATTACH_GUI_FAILED

[former_member188886]

DS 3.2 u201CDirect Downloadu201D from SAP ECC Dump RFC_ATTACH_GUI_FAILED - Start 'sapgui' failed

We are running DS 3.2.1 with a data source connected to ECC 6.0 using u201CDirect Downloadu201D.

DS 3.2 Designer on Windows, DS Job server on Unix, SAP ECC running on Unix (different Unix box than DS).

We get a dump in the SAP ECC source system, RFC_ATTACH_GUI_FAILED Start 'sapgui' failed.

DETAILS

From the DS Designer

- We can view the data in the SAP ECC T001 table from the ECC Data Source.

- Run the job from the DS designer on the DS Unix server, jobs starts the ABAP Data flow, then gets the error:

>Cannot connect to SAP Applications datastore <DS_JR_ERD100_TEST> using host <ierpt1>, client <100>, user <G6992JR>, and system number <27: CRFC error: Start 'sapgui' failed.>. Please make sure the SAP server is running and the login information is correct.

- In the SAP ECC source system Tran ST22 I see the following dump:

>Runtime Errors RFC_ATTACH_GUI_FAILED

>Start 'sapgui' failed.

>u2026

>Call Program........."al_engine"

>Function Module..... "SYSTEM_RFC_VERSION_3_INIT"

>u2026

>Termination occurred in the ABAP program "SAPLSYST" - in "SYSTEM_ATTACH_GUI".

>The main program was "SAPMSSY1 ".

-Data Store to SAP ECC settings:

o ABAP Execution Option: Generate and Execute

o Execute in Background: No

o Data Transfer Method: Direct Download

o Working dir on Sap server: ECC Server, no files show here.

o Local Directory: DS Server, no files here

o Generated ABAP Dir: DS Unix server, the ABAP program is here.

Has anyone seen this issue?

Shouldnu2019t it use WS_DOWNLOAD vs. GUI_DOWNLOAD?

[former_member232794]

Hi Jay

I have the same problem with a Rapid Mart deployment.

The optimal method used by RM is shared directory:

FOR WINOWDS Job Server

In your Initialize Job Script add the command:

"exec('cmd.exe','net use

srvmachine\shared_work_dir /USER:srvmachine

user pwd',0);"

FOR UNIX Job Server use similar batch command in init script.

With this workaround you enable Jobserver to access remote directory on ECC Server on another domain.

[werner_daehn]

ws_download and gui_download are the same, except that the old ws_download does not support unicode and can't be used hence.

To me it looks that on the server there is no SAP GUI installed and hence both function modules cannot work. But frankly, why are you using direct_download at all? It is for testing only, not for larger volumes of data.

[former_member188886]

Thanks for the information on the Direct Download.

I will check test by running the generated ABAP in the SAP ECC system to see why we get the GUI ERROR.

I now understand that Direct Download is for testing & small amounts of data & "Old" functionality.

We were doing a test on a table with only 87 records.

We wanted to test that we could connect from DS to the SAP ECC system & that the DS Data Flow worked.

Also, our SAP ECC & our Data Services are on different Unix servers that do NOT have a common directory.

So if we used Shared Directory, the file would be deposited on the SAP Server, but the DS server would not be able to see it to pick it up. So we may have to look at FTP option.

Has anyone used DS to extract from an SAP ECC on a Unix server to Data Services on a DIFFERENT Unix server with no common directory?

We would really prefere NOT to have to create a temporary file, but would rather it worked just like the BW extracts from SAP ECC, it just sends the records over via TRFC's, not temp file, or if it woudl work the same way as when DS pulls from one oracle DB on a Unix server to another oracle DB on a Different Unix server, I don't think that creates temporary files.

Thanks Again for your help

Jay Roble

[werner_daehn]

I agree, there should be a "streaming" transport method. But no matter what I do, each solution has a downside. What I need to check carefully next is the theoretical throughput of the RFC protocol at all. If that is a slow as the ws_download I will forget about it right away.

The next feasable step I foresee is that we add RFC calls in the DS genereated ABAP sending the batch of data down to the RFCServer of DS and write a file there. And then we can attack the streaming.

If you happen to have an idea on how the streaming could be done I would appreciate your thoughts.

If shared_directory cannot be setup, ftp or custom_transport are your only options left.

https://wiki.sdn.sap.com/wiki/display/BOBJ/ChosingtheTransport+Method

[Former Member]

Hi Jay,

Question? Cant you not mount the SAP server working directory on you DS Linux server and then used your application shared directory to access the .dat file created.

If the above method is not acceptable , you are left with three choices

1) Custom Transfer method (ie., any third party Trs tool) - SAP security wouldnt allow that in our orgnztn

2) FTP Transfer -- Would SAP security allow you to do so?

3) The worst of all , is you have to split the job into two one which extracts the data and writes to working directory .dat file , use a custom function on SAP to move the file from working to you linux server and then second job to read the file from you DS linux directory

Thanks

AJ