on 01-17-2019 8:26 AM
Hi expertes,
I'm using a web service to upload files to my application server. With this files, I create document info records but as soon as I try to show the file(original) inside CV02/03 I'm receiving the message file could not be accessed. (see screenshot). Do you have any idea what could cause this problem? I can open the file in al11 as you can see in the screenshot.
Code for file generation:
CONCATENATE '/tmp/' SY-UNAME '.txt' INTO LV_FILENAME.
DATA: BINDATA type XSTRING.
CALL FUNCTION 'SSFC_BASE64_DECODE'
EXPORTING
B64DATA = STRING
* B64LENG =
* B_CHECK =
IMPORTING
BINDATA = BINDATA
EXCEPTIONS
SSF_KRN_ERROR = 1
SSF_KRN_NOOP = 2
SSF_KRN_NOMEMORY = 3
SSF_KRN_OPINV = 4
SSF_KRN_INPUT_DATA_ERROR = 5
SSF_KRN_INVALID_PAR = 6
SSF_KRN_INVALID_PARLEN = 7
OTHERS = 8
.
IF SY-SUBRC <> 0.
* Implement suitable error handling here
ENDIF.
CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
EXPORTING
BUFFER = BINDATA
* APPEND_TO_TABLE = ' '
IMPORTING
OUTPUT_LENGTH = LV_OUTPUT_LENGTH
TABLES
BINARY_TAB = LT_SOLIX_TAB
.
IF NOT LT_SOLIX_TAB IS INITIAL.
OPEN DATASET LV_FILENAME FOR OUTPUT IN BINARY MODE.
LOOP AT LT_SOLIX_TAB INTO LS_SOLIX.
TRANSFER LS_SOLIX TO LV_FILENAME.
ENDLOOP.
CLOSE DATASET LV_FILENAME.
ENDIF.
This part:
OPEN DATASET LV_FILENAME FOR OUTPUT IN BINARY MODE.
LOOP AT LT_SOLIX_TAB INTO LS_SOLIX.
TRANSFER LS_SOLIX TO LV_FILENAME.
ENDLOOP.
You can not upload binary file by fixed length (size of one SOLIX line) parts.
Example: your file has 200 bytes, but SOLIX line is 255 bytes. So this code is transfering whole 255 bytes and makes corrupted file (file will not be 200 bytes big). You can even see it in your AL11 screenshot. You are always creating file where "file_size MOD 255 = 0"...
Either transfer xstring in one TRANSFER command. Or keep in mind transfered bytes in loop and use TRANSFER ... LENGTH ... addition.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Tomas, thanks for your answer.
I changed my code to.
OPEN DATASET LV_FILENAME FOR OUTPUT IN BINARY MODE.
TRANSFER BINDATA to LV_FILENAME.
CLOSE DATASET LV_FILENAME.
My file looks in the AL11 view now much better. But even now the system says that it can't access the file. Do you have any further idea which could cause the problem?
My user is working with SAP_ALL which shouldn't cause any permission error.
Hi danielfulda,
then it is either wrong source data, or wrong used function for base64 (SSFC_BASE64_DECODE is unreleased BTW).
Try check your data and try another methods to manipulate with base64. I would recommend CL_HTTP_UTILITY base64 methods (reminder - there are "_X_" methods for xstring and other for string data).
To be honest, the "CA-DMS" APIs (BAPI_DOCUMENT_*) are really tricky for using SAPFTPA without KPRO storage (well it's said "old storage" in the docs, so maybe simply we should not use it anymore because not well supported, anyway let's try...)
Even by reading tens of threads, blog posts and official documentation, and good forum assistances from christoph.hopf (BTW unfortunately I don't find the official documentation so well written!), there's no clear indication how to use it, combined with SAP patches which may need to be applied, and unclear error messages.
I could finally make it work with a big debug assistance, in my S/4HANA 1709 (S4CORE 102 SP 0 + applied the note 2408047 in advance, although this note theorically only applies to checkout, but it seems it's also needed for checkins, tell SAP so !).
To simplify the code to upload one file from the application server, I assumed the file already exists in the file system, and that a document already exists in CV03N without any original file. You must also run it via a background job:
" For CA-DMS, SAPFTPA works only if "GUI is detached", simplest way is background job
" (checked in S/4HANA 1709 with S4CORE 102 SP 0 + applied the note 2408047 in advance,
" in function module CV120_FTP_START_REG_SERVER which does a RFC_PING 'SAPGUI')
DATA: ls_draw TYPE draw,
ls_return LIKE bapiret2,
lt_documentfiles LIKE bapi_doc_files2 OCCURS 0 WITH HEADER LINE,
lt_documentfiles_new LIKE bapi_doc_files2 OCCURS 0 WITH HEADER LINE.
CHECK sy-batch = 'X'. " simple test for background job
" This memory ID requires the note 2408047 to be installed although
" it's specific to checkout, it is required also for checkin !
DATA ftp_client_rfc_destination LIKE rfcdes-rfcdest.
CONSTANTS memid_ftp_client(60) TYPE c VALUE 'FTP_CLIENT:RFC_DESTINATION'.
ftp_client_rfc_destination = 'SAPFTPA'.
EXPORT ftp_client_rfc_destination TO MEMORY ID memid_ftp_client.
ls_draw-doknr = 'LBL_AVLON_TEST'.
ls_draw-dokar = 'SBV'. " defined in DC10 with "use kpro" UN-CHECKED
ls_draw-doktl = '000'.
ls_draw-dokvr = '01'.
lt_documentfiles[] = VALUE #( (
originaltype = '1' " needed "If the original is to be checked into the old storage"
storagecategory = 'SAP-SYSTEM' " system value, no need to define it in DC20 !
" Means that the file will be stored in table DRAO.
docfile = '/tmp/sandra/ASE license procedure.pdf'
description = 'Sample Description2'
wsapplication = 'PDF' ) ).
DATA return TYPE bapiret2.
CALL FUNCTION 'BAPI_DOCUMENT_CHECKIN2'
EXPORTING
documenttype = ls_draw-dokar
documentnumber = ls_draw-doknr
documentpart = ls_draw-doktl
documentversion = ls_draw-dokvr
pf_ftp_dest = 'SAPFTPA'
pf_http_dest = 'SAPHTTPA' " not used
IMPORTING
return = return
TABLES
documentfiles = lt_documentfiles.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
wait = 'X'.
Then I go to CV03N, I see that the file has been added in both tabs "document data" and "original files", and the display is successful (note that it works even if the file is removed from the application server because it's loaded from the table DRAO which is initialized during the checkin)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sandra thank you so much for your help 🙂
Take a look at the following post. Hope it helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
98 | |
12 | |
10 | |
6 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.