Reg. Error in Commit work in FM "SO_NEW_DOCUMENT_ATT_SEND_API1"

Dear Experts,
My requirement is that i need to send the PDF attachment via Outlook Express as Mail. I am using the FM "SO_NEW_DOCUMENT_ATT_SEND_API1" for sending to Outlook Express. Here i need to check "Commit work" flag. Else it will not be sent to the mail. When i do this, i am getting the short dump saying "MESSAGE_TYPE_X" - Pre_commit check.
Is the above issue related to any configuration settings done by Basis. I checked the forum but i could not get suitable post.
Kindly help me in this regard.
Regards,
Ramesh Manoharan

Hi Ramesh,
Check subrc and RETRN_CODE value for the table RECEIVERS. If subrc is inintial and Return_code is fine.
Then check with your basis team. They might need to do some config change.
I have used used a Z-FM to do this job. Find the code below.
FUNCTION z_send_pdf_2_email .
*"*"Local Interface:
*" IMPORTING
*"     VALUE(EMAILID) TYPE INTAD
*"     VALUE(SUBJECT) TYPE CHAR200
*"     VALUE(ATTACH_NAME) TYPE CHAR200
*"     VALUE(PONUM) TYPE EBELN
*"     VALUE(PODATE) TYPE BEDAT
*" EXPORTING
*"     REFERENCE(RETURN) TYPE SUBRC
*" TABLES
*"      I_OTF STRUCTURE ITCOO
TYPES : t_record TYPE solisti1,
          t_objpack TYPE sopcklsti1,
          t_objtxt TYPE solisti1,
          t_reclist TYPE somlreci1.
DATA : l_lines_bin TYPE i,
         l_lines_txt TYPE i,
         l_len_in TYPE sood-objlen,
         l_date TYPE char10,
         i_record TYPE TABLE OF t_record,
         i_objpack TYPE TABLE OF t_objpack,
         i_objtxt TYPE TABLE OF t_objtxt,
         i_objbin TYPE TABLE OF t_objtxt,
         i_reclist TYPE TABLE OF t_reclist,
         i_tline TYPE TABLE OF tline,
         w_record TYPE t_record,
         w_objpack TYPE t_objpack,
         w_objtxt TYPE t_objtxt,
         w_objbin TYPE t_objtxt,
         w_reclist TYPE t_reclist,
         w_tline TYPE tline,
         w_doc_chng TYPE sodocchgi1,
         w_buffer TYPE string,
         w_objhead TYPE soli_tab.
CONSTANTS: c_smart(5) TYPE c VALUE 'SMART',
           c_u TYPE c VALUE 'U',
           c_raw(3) TYPE c VALUE 'RAW',
           c_f TYPE c VALUE 'F',
           c_pdf(3) TYPE c VALUE'PDF',
           c_x TYPE c VALUE 'X'.
* Convert OTF data to PDF
CALL FUNCTION 'CONVERT_OTF'
    EXPORTING
      format                = c_pdf
      max_linewidth         = 132
    IMPORTING
      bin_filesize          = l_len_in
    TABLES
      otf                   = i_otf
      lines                 = i_tline
    EXCEPTIONS
      err_max_linewidth     = 1
      err_format            = 2
      err_conv_not_possible = 3
      err_bad_otf           = 4
      OTHERS                = 5.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
LOOP AT i_tline INTO w_tline.
    TRANSLATE w_tline USING '~'.
    CONCATENATE w_buffer w_tline INTO w_buffer.
ENDLOOP.
TRANSLATE w_buffer USING '~'.
DO.
    w_record = w_buffer.
    APPEND w_record TO i_record.
    SHIFT w_buffer LEFT BY 255 PLACES.
    IF w_buffer IS INITIAL.
      EXIT.
    ENDIF.
ENDDO.
* Attachment
REFRESH: i_reclist,
i_objtxt,
i_objbin,
i_objpack.
CLEAR w_objhead.
i_objbin[] = i_record[].
CONCATENATE podate+6(2) '.' podate+4(2) '.' podate(4) INTO l_date.
* Create Message Body Title and Description
w_objtxt = text-003.
APPEND w_objtxt TO i_objtxt.
CLEAR w_objtxt.
CONCATENATE l_date text-004 ponum text-005 INTO w_objtxt SEPARATED BY space.
APPEND w_objtxt TO i_objtxt.
CLEAR: w_objtxt, l_date.
w_objtxt = text-006.
APPEND w_objtxt TO i_objtxt.
CLEAR w_objtxt.
w_objtxt = space.
APPEND w_objtxt TO i_objtxt.
CLEAR w_objtxt.
w_objtxt = text-007.
APPEND w_objtxt TO i_objtxt.
CLEAR w_objtxt.
w_objtxt = space.
APPEND w_objtxt TO i_objtxt.
CLEAR w_objtxt.
w_objtxt = text-008.
APPEND w_objtxt TO i_objtxt.
CLEAR w_objtxt.
DESCRIBE TABLE i_objtxt LINES l_lines_txt.
READ TABLE i_objtxt INTO w_objtxt INDEX l_lines_txt.
w_doc_chng-obj_name = subject.
w_doc_chng-expiry_dat = sy-datum + 10.
w_doc_chng-obj_descr = subject.
w_doc_chng-sensitivty = c_f.
w_doc_chng-doc_size = l_lines_txt * 255.
*Main Text
CLEAR w_objpack-transf_bin.
w_objpack-head_start = 1.
w_objpack-head_num = 0.
w_objpack-body_start = 1.
w_objpack-body_num = l_lines_txt.
w_objpack-doc_type = c_raw.
APPEND w_objpack TO i_objpack.
CLEAR w_objpack.
* Attachment (pdf-Attachment)
w_objpack-transf_bin = c_x.
w_objpack-head_start = 1.
w_objpack-head_num = 0.
w_objpack-body_start = 1.
DESCRIBE TABLE i_objbin LINES l_lines_bin.
READ TABLE i_objbin INTO w_objbin INDEX l_lines_bin.
w_objpack-doc_size = l_lines_bin * 255 .
w_objpack-body_num = l_lines_bin.
w_objpack-doc_type = c_pdf.
w_objpack-obj_name = c_smart.
w_objpack-obj_descr = attach_name.
APPEND w_objpack TO i_objpack.
CLEAR w_reclist.
w_reclist-receiver = emailid.
w_reclist-rec_type = c_u.
APPEND w_reclist TO i_reclist.
CLEAR:w_reclist.
* Send Mail
CALL FUNCTION 'SO_NEW_DOCUMENT_ATT_SEND_API1'
    EXPORTING
      document_data              = w_doc_chng
      put_in_outbox              = c_x
*      commit_work                = c_x
    TABLES
      packing_list               = i_objpack
      object_header              = w_objhead
      contents_bin               = i_objbin
      contents_txt               = i_objtxt
      receivers                  = i_reclist
    EXCEPTIONS
      too_many_receivers         = 1
      document_not_sent          = 2
      document_type_not_exist    = 3
      operation_no_authorization = 4
      parameter_error            = 5
      x_error                    = 6
      enqueue_error              = 7
      OTHERS                     = 8.
IF sy-subrc <> 0.
ENDIF.
READ TABLE i_reclist INTO w_reclist INDEX 1.
IF sy-subrc IS INITIAL.
    return = w_reclist-retrn_code.
ENDIF.
*Clear Refresh Data
CLEAR: l_lines_bin,
         l_lines_txt,
         l_len_in,
         i_record,
         i_objpack,
         i_objtxt,
         i_objbin,
         i_reclist,
         i_tline,
         w_record,
         w_objpack,
         w_objtxt,
         w_objbin,
         w_reclist,
         w_tline,
         w_doc_chng,
         w_buffer,
         w_objhead.
REFRESH:i_record,
         i_objpack,
         i_objtxt,
         i_objbin,
         i_reclist,
         i_tline.
ENDFUNCTION.

Similar Messages

Error with commit work

Hi everybody.
I have a standar aplication with this instruction. If I execute the program directly, it raise an exception. But if I active the debug, stop in the line of this instruction, and press F6 to execute the "commit work", and then press F8, it work correctly. If I activate the debug at the star of program, and pres F8 directly, it raise the exception too.
Summary:
Break point at line "commit work".
Run the aplication
The execution stop at the break point
Press F8
ERROR (exception)
Break point in other previous point of the program
Run the aplication
The execution stop at the break point
Press F8
ERROR (exception)
Break point at line "commit work"
Run the aplication
The execution stop at the break point
Press F6 (it jump to the next line)
Press F8
FINISH FINE
The exception is this (is in a BSP):
An exception has occurred Exception Class CX_BOL_EXCEPTION - Access Previously Deleted Entity
Method: CL_CRM_BOL_CORE=>REREAD_ENTITY
Source Text Row: 118
And this is the code that raise the exception:
if IV_ENTITY->MY_MANAGER_ENTRY is not bound or IV_ENTITY->CONTAINER_PROXY is not bound.
entity does not longer exist
    raise exception type CX_BOL_EXCEPTION
      exporting
        TEXTID = CX_BOL_EXCEPTION=>ENTITY_ALREADY_FREED.
endif.
But the commit is previos than this...
Thanks, experts

hi
chk this statement
if sy-subrc <> 0.
message s208(00) with 'Error'. --> where will the status bar msg. occur in bground
leave list-processing.
endif.
maybe the subrc might be false, and triggering this condition, which i believe will not work in background
if helpful, reward
Sathish. R

COMMIT WORK AND WAIT USE

Hi Friends,
what is mean by COMMIT WORK AND WAIT.
when we use ths syntax...??
situation pls.
regards,
venu.

Hi,
To apply the changes made to the runtime objects of persistent classes to the actual persistent objects in the database, execute the COMMIT WORK statement. (Alternatively, use COMMIT WORK AND WAIT or SET UPDATE TASK LOCAL). Unless you are executing an object-oriented transaction from within the Transaction Service, you must include the COMMIT WORK statement explicitly in the program. Otherwise, it is encapsulated in the Transaction Service. (If you explicitly include the COMMIT WORK statement as described here, the t op-level transaction runs in compatibility mode).
The function of the COMMIT WORK statement is extended when you use it in conjunction with Object Services. Before COMMIT WORK closes the SAP LUW and triggers an update, it calls internal methods of the Persistence Service. These methods bundle the changes made to managed objects of the Persistence Service and pass them to a special update function module using CALL FUNCTION ... IN UPDATE TASK. Thus the Persistence Service works with traditional update methods. The update module is usually registered after any update modules that have already been registered. The update is then triggered and the update task executes the update module in the order in which they were registered.
After the system executes the COMMIT WORK statement, it sets the attributes of each persistent object in the ABAP program to initial. (That is, it calls the IF_OS_STATE~INVALIDATE method).
Local Update
If you want to change managed objects directly, rather than using the update module, you must change the update mode of the implicitly used Transaction Service. That is, the following statements must be executed before the COMMIT WORK statement:
DATA TM type ref to IF_OS_TRANSACTION_MANAGER.
DATA T type ref to IF_OS_TRANSACTION.
TM = CL_OS_SYSTEM=>GET_TRANSACTION_MANAGER( ).
T = TM->GET_CURRENT_TRANSACTION( ).
T->SET_MODE_UPDATE( OSCON_DMODE_DIRECT ).
COMMIT WORK.
To ensure database consistency, the local update is activated internally using SET UPDATE TASK LOCAL. In such cases, the system raises an exception if there are already update modules registered in the update task. You can only register additional classical update modules after setting the mode. They will then also be updated locally.
COMMIT
Basic form
COMMIT WORK.
Addition
... AND WAIT
Effect
Executes a database commit and thus closes a logical processing unit or Logical Unit of Work ( LUW ) (see also Transaction processing ). This means that
all database changes are made irrevocable and cannot be reversed with ROLLBACK WORK and
all database locks are released.
COMMIT WORK also
calls the subroutines specified by PERFORM ... ON COMMIT ,
executes asynchronously any update requests (see CALL FUNCTION ... IN UPDATE TASK ) specified in these subroutines or started just before,
processes the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK ,
cancels all existing locks (see SAP locking concept ) if no update requests exist,
closes all open database cursors (see OPEN CURSOR ) and
resets the time slice counter to 0.
COMMIT WORK belongs to the Open SQL command set.
Return code value
The SY-SUBRC is set to 0.
Notes
All subroutines called with PERFORM ... ON COMMIT are processed in the LUW concluded by the COMMIT WORK command. All V1 update requests specified in CALL FUNCTION ... IN UPDATE TASK are also executed in one LUW . When all V1 update requests have been successfully concluded, the V2 update requests ("update with start delayed") are processed, each in one LUW . Parallel to this, the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK are each executed in one LUW per destination.
COMMIT WORK commands processed within CALL DIALOG processing
- execute a database commit (see above),
- close all open database cursors,
- reset the time slice counter and
- call the function modules specified by CALL FUNCTION IN
BACKGROUND TASK in the CALL DIALOG processing.
However, subroutines and function modules called with PERFORM ... ON COMMIT or CALL FUNCTION ... IN UPDATE TASK in the CALL DIALOG processing are not executed in the calling transaction until a COMMIT WORK occurs.
Since COMMIT WORK closes all open database cursors, any attempt to continue a SELECT loop after a COMMIT WORK results in a runtime error. For the same reason, a FETCH after a COMMIT WORK on the now closed cursors also produces a runtime error. You must therefore ensure that any open cursors are no longer used after the COMMIT WORK .
With batch input and CALL TRANSACTION ... USING , COMMIT WORK successfully concludes the processing.
Addition
... AND WAIT
Effect
The addition ... AND WAIT makes the program wait until the type V1 updates have been completed.
The return code value is set as follows:
SY-SUBRC = 0 The update was successfully performed.
SY-SUBRC <> 0 The update could not be successfully performed.
Note
Runtime errors
COMMIT_IN_PERFORM_ON_COMMIT : COMMIT WORK is not allowed in a FORM callled with PERFORM ... ON COMMIT .
COMMIT_IN_POSTING : COMMIT WORK is not allowed in the update task.
if its useful reward points

Commit work functionality

Hello all,
can anyone explain me what is commit work mean.
Thanks & Regards
venkata prasad

Hello
Check this
Syntax Diagram
COMMIT
Basic form
COMMIT WORK.
Addition:
... AND WAIT
Effect
Executes a database commit and thus closes a Logical Unit of Work ( LUW) (see also Transaction Processing). This means that
all database updates are made irrevocable and cannot be reversed with ROLLBACK WORK and
all database locks are released.
COMMIT WORK also
calls the subroutines specified by PERFORM ... ON COMMIT,
executes asynchronously any update requests (see CALL FUNCTION ... IN UPDATE TASK) specified in these subroutines or started just before,
processes the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK,
closes all open database cursors (see OPEN CURSOR) and
resets the time slice counter to 0.
COMMIT WORK belongs to the Open SQL command set.
The return code SY-SUBRC is set to 0.
Notes
All subroutines called with PERFORM ... ON COMMIT are processed in the LUW concluded by the COMMIT WORK command. All V1 update requests specified in CALL FUNCTION ... IN UPDATE TASK are also executed in one LUW. When all V1 update requests have been successfully concluded, the V2 update requests ("update with start delayed") are processed, each in one LUW. Parallel to this, the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK are each executed in one LUW per destination.
COMMIT WORK commands processed within CALL DIALOG processing
- execute a database commit (see above),
- close all open database cursors,
- reset the time slice counter and
- call the function modules specified by CALL FUNCTION IN
BACKGROUND TASK in the CALL DIALOG processing.
However, subroutines and function modules called with PERFORM ... ON COMMIT or CALL FUNCTION ... IN UPDATE TASK in the CALL DIALOG processing are not executed in the calling transaction until a COMMIT WORK occurs.
Since COMMIT WORK closes all open database cursors, any attempt to continue a SELECT loop after a COMMIT WORK results in a runtime error. For the same reason, a FETCH after a COMMIT WORK on the now closed cursors also produces a runtime error. You must therefore ensure that any open cursors are no longer used after the COMMIT WORK.
With batch input and CALL TRANSACTION ... USING, COMMIT WORK successfully concludes the processing.
Addition
... AND WAIT
Effect
The addition ... AND WAIT makes the program wait until the type V1 updates have been completed.
The return code is set as follows:
SY-SUBRC = 0:
The update was successfully performed.
SY-SUBRC <> 0:
The update could not be successfully performed.
Note
Runtime errors:
COMMIT_IN_PERFORM_ON_COMMIT: COMMIT WORK is not allowed in a FORM called with PERFORM ... ON COMMIT.
COMMIT_IN_POSTING: COMMIT WORK is not allowed in the update task.
Additional help
Making Database Changes Permanent
If useful reward.
Vasanth

Commit work sets sy-subrc 0

I
Commit work sets sy-subrc always to zero.
In this case how can we know if commit work fails.
Please provide more details and efficient usage of commit statements in a report

Hi,
Usage of commit statements is as follows:
COMMIT WORK.
Addition
u2026 AND WAIT
Effect
Executes a database commit and thus closes a logical processing unit or Logical Unit of Work ( LUW ) (see also Transaction processing ). This means that
all database changes are made irrevocable and cannot be reversed with ROLLBACK WORK and
all database locks are released.
COMMIT WORK also
calls the subroutines specified by PERFORM u2026 ON COMMIT ,
executes asynchronously any update requests (see CALL FUNCTION u2026 IN UPDATE TASK ) specified in these subroutines or started just before,
processes the function modules specified in CALL FUNCTION u2026 IN BACKGROUND TASK ,
cancels all existing locks (see SAP locking concept ) if no update requests exist,
closes all open database cursors (see OPEN CURSOR ) and
resets the time slice counter to 0.
COMMIT WORK belongs to the Open SQL command set.
Return code value
The SY-SUBRC is set to 0.
Notes
All subroutines called with PERFORM u2026 ON COMMIT are processed in the LUW concluded by the COMMIT WORK command. All V1 update requests specified in CALL FUNCTION u2026 IN UPDATE TASK are also executed in one LUW . When all V1 update requests have been successfully concluded, the V2 update requests (u201Dupdate with start delayedu201D) are processed, each in one LUW . Parallel to this, the function modules specified in CALL FUNCTION u2026 IN BACKGROUND TASK are each executed in one LUW per destination.
COMMIT WORK commands processed within CALL DIALOG processing
- execute a database commit (see above),
- close all open database cursors,
- reset the time slice counter and
- call the function modules specified by CALL FUNCTION IN
BACKGROUND TASK in the CALL DIALOG processing.
However, subroutines and function modules called with PERFORM u2026 ON COMMIT or CALL FUNCTION u2026 IN UPDATE TASK in the CALL DIALOG processing are not executed in the calling transaction until a COMMIT WORK occurs.
Since COMMIT WORK closes all open database cursors, any attempt to continue a SELECT loop after a COMMIT WORK results in a runtime error. For the same reason, a FETCH after a COMMIT WORK on the now closed cursors also produces a runtime error. You must therefore ensure that any open cursors are no longer used after the COMMIT WORK .
With batch input and CALL TRANSACTION u2026 USING , COMMIT WORK successfully concludes the processing.
Addition
u2026 AND WAIT
Effect
The addition u2026 AND WAIT makes the program wait until the type V1 updates have been completed.
The return code value is set as follows:
SY-SUBRC = 0 The update was successfully performed.
SY-SUBRC <> 0 The update could not be successfully performed.
Note
Runtime errors
COMMIT_IN_PERFORM_ON_COMMIT : COMMIT WORK is not allowed in a FORM callled with PERFORM u2026 ON COMMIT .
COMMIT_IN_POSTING : COMMIT WORK is not allowed in the update task.
Hope it will help you.
Feel free to ask any doubt.
Regards
Aparna

Reg. commit work in a follow-up action

friends
i am using the following approach to solve a requirement which is posted in this thread..How to send a mail after a usage decision is made in QA11?
got a nice reply too
i have defined a follow-up action and assigned a customized mail-sending fm to it..my doubts are, i am on 4.7..am able to send the mail to an internal id, but the problem is without using commit work and submit rsconn01 commands, am failing in doing the same...i have read in a thread that commit work or submit (if the called program uses commit work) will cause data inconsistencies and will trigger locks if it's used in any user-exit or badi...but in my case, when will a follow-up action actually take place? will it happen after all the database commits? if so, then i believe that even i use commit work and submit commands in my z mail sending fm, it wouldn't cause any problems...am just sort of afraid whether this approach is the correct one? or triggering the mail code from the last user exit or badi itself will solve the purpose? i believe not..please guide me on this friends...helpful replies will be appreciated and awarded..thanks in advance
Regards,
Sathish. R

less views and no answers:-(

Reg. Commit Work Response time

Hi All,
Could you please let me know to which factors the response of the Commit work belong to.
Regards,
Sen

Hi,
Commit work for the database tables.
Regards,
Naresh.

Reg. commit work

friends,
i have defined a follow-up action for txn qa11/12 and assigned a customized mail-sending fm to it..am on 4.7 and to send the mail to an internal lotus notes id using so_new_document_send_api1, but the problem is without using commit work and submit rsconn01 commands, am failing in doing the same...just want to make sure that my follow-up action will take place after all the database commits and will not cause any problems? ..please guide me on this friends...thanks in advance
regards,
Sathish. R

hi
thanks for your response...but QFOA_MAIL_SENDING_STANDARD is the fm used by a standard follow-up action that sends a mail to user's SAP office...that fm uses so_object_send to send the mail, which finally calls a commit work...just in a general sense, i hope follow up action triggers after all database commits..correct me if am wrong...i've never used perform on commit...any suggestions will be of great help
regards
Sathish. R

How to use commit work in class cl_bls

Hi,
When i have used commit work after email sent,
it goes into dump.
Here is the code segment:
try.
    -------- create persistent send request ------------------------
      send_request = cl_bcs=>create_persistent( ).
    -------- create and set document -------------------------------
      pdf_content = cl_document_bcs=>xstring_to_solix( pdf_tab ).
      document = cl_document_bcs=>create_document(
            i_type    = 'PDF'
            i_hex     = pdf_content
            i_length = bytecount
            i_subject = sub ). "#EC NOTEXT
    add document object to send request
      send_request->set_document( document ).
    --------- add recipient (e-mail address) -----------------------
    create recipient object
      recipient = cl_cam_address_bcs=>create_internet_address( recip-recip ).
    add recipient object to send request
      send_request->add_recipient( recipient ).
    ---------- send document ---------------------------------------
      sent_to_all = send_request->send( i_with_error_screen = 'X' ).
     commit work.
      if sent_to_all is initial.
        message i500(sbcoms) with recip.
      else.
        message s022(so).
      endif.
------------ exception handling ----------------------------------
replace this rudimentary exception handling with your own one !!!
    catch cx_bcs into bcs_exception.
      message i865(so) with bcs_exception->error_type.
endtry.
What could be the reason?
Is there any way to use commit work in class while sending email as in SO_NEW_DOCUMENT_ATT_SEND_API1 fm?
Thanks.

Hi,
I have used
submit program.....
but in update task i have used it.
"Z_SD_ORDER_UPDATE".    program is a print driver program.
However error says:
There is probably an error in the program
"Z_SD_ORDER_UPDATE".
This program is triggered in the update task. There, the
following ABAP/4 statements are not allowed:
- CALL SCREEN
- CALL DIALOG
- CALL TRANSACTION
- SUBMIT
I used submit as:
WAIT UP TO 2 SECONDS.
SUBMIT rsconn01 WITH mode = 'INT'
                  WITH output = ' '
                AND RETURN.
Instead of submit i want to use commit work but i also get a dump after commit work too.
How can i use commit work in above code?
Thanks.

Commit work not working in Routine for Transaction because of LUW

Hi all,
i have req to send adobe PDF as attachement by email.
Basically i am calling adobe from output type of VL02n .
Inside this i can not use commit work because of LUW.Please suggest what should i do.
so not able to send email in green status.
i am using below code
TRY.
      zlcl_send_request->set_document( zlcl_document ).
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
Email sender
TRY.
      zlcl_sender = cl_sapuser_bcs=>create( sy-uname ).
    CATCH cx_address_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
TRY.
      CALL METHOD zlcl_send_request->set_sender
        EXPORTING
          i_sender = zlcl_sender.
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
Create the Reciever address
TRY.
      zlcl_recipient = cl_cam_address_bcs=>create_internet_address(
                                         gv_email ).
    CATCH cx_address_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
TRY.
      zlcl_send_request->add_recipient( EXPORTING i_recipient =
      zlcl_recipient ).
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
TRY.
      zlcl_send_request->set_send_immediately( gc_x ).
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
Send the mail
TRY.
      zlcl_send_request->send( ).
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.

Hi
From abap help:
SY-ONCOM
On Commit flag. This system field is set to different values depending on the call status of an ABAP program. Of these, only the value of u2018Pu2019 is guaranteed. If at all, SY-ONCOM must only be queried for u2018Pu2019.
The value 'P' means that the program is already executing a subroutine started using PERFORM u2026 ON COMMIT and therefore a
further subroutine call using PERFORM ... ON COMMIT would cause a runtime error.
That means the variable SY-ONCOM has the information if a process "ON COMMIT" is working and so it determines if a dump has to be raised.
Now it's clear the meaning of that correction: if before calling a new commit the value of SY-ONCOM is changed the dump will be avoided.
I've done the following texts:
REPORT ZCOMMIT.
WRITE: 'Calling routine on commit'.
PERFORM DO_SOMETHING ON COMMIT.
COMMIT WORK.
FORM DO_SOMETHING.
DATA: ONCOM TYPE SY-UCOMM.
MOVE SY-ONCOM TO ONCOM.
SY-ONCOM = 'S'.
COMMIT WORK.
MOVE ONCOM TO SY-ONCOM.
ENDFORM.
The code above is very dangerous, because it triggeres a ricorsive loop: no dump, but the form is continuously called, just as help says SY-ONCOM is equal to P
REPORT ZCOMMIT.
WRITE: 'Calling routine on commit'.
CALL FUNCTION 'Z_MAX_COMMIT' IN UPDATE TASK.
COMMIT WORK.
FUNCTION Z_MAX_COMMIT.
DATA: ONCOM TYPE SY-UCOMM.
MOVE SY-ONCOM TO ONCOM.
SY-ONCOM = 'S'.
COMMIT WORK.
MOVE ONCOM TO SY-ONCOM.
ENDFUNCTION.
I expected the same behavior as above, but here no dump and no infinite loop, SY-ONCOM = V
Now your process working in update task, but probably many function are called, I mean the system creates a queue of functions to be run in update task, so what happens here?
I've tried this:
FUNCTION Z_MAX_COMMIT.
*"*"Function module di reg.:
*"*"Interfaccia locale:
*" IMPORTING
*"     VALUE(NO_COMMIT) TYPE FLAG DEFAULT SPACE
CHECK NO_COMMIT IS INITIAL.
DATA: ONCOM TYPE SY-UCOMM.
MOVE SY-ONCOM TO ONCOM.
SY-ONCOM = 'S'.
COMMIT WORK.
MOVE ONCOM TO SY-ONCOM.
ENDFUNCTION.
REPORT ZCOMMIT.
WRITE: 'Calling routine on commit'.
CALL FUNCTION 'Z_MAX_COMMIT' IN UPDATE TASK
EXPORTING
    NO_COMMIT = 'X'.
CALL FUNCTION 'Z_MAX_COMMIT' IN UPDATE TASK.
CALL FUNCTION 'Z_MAX_COMMIT' IN UPDATE TASK
EXPORTING
    NO_COMMIT = 'X'.
COMMIT WORK.
Here no dump and no infinite loop too, but also no impact on the rest of the functions,
I can suppose the impact will be on the saving of data on database only, because your COMMIT ends the LUW, so it's very important the routine for printing is called at the end, after all saving routines.
Max

CO54: Message is not sent to any destination: Commit Work is getting failed

Hello,
While processing the Messages from XFP to SAP Update is getting terminated due to the use of Commit Work. SAP Note 147467 - Update termination when sending process messages has been referred which is for 4.6C, but we are in ECC6.0.
While processing the message in second iteration Commit Work triggres and Update happens in the data base.
Following Issue is only concerned with Nested HUs
T-Code used CO54
Following are the analysis:
it looks like u201CCreate and Post a Physical Inventory Docu201D is failing in the initial processing because the inventory doc is created when the Transfer Order to the PSA (or the TO from the PSA) is not yet completed (quant is still locked somehow).
CO54, process message category=ZHU_CONS: HU to be consumed is a nested pallet (unpacking/ repacking and TOs to/from) and qty to consume is greater that HU qty in SAP (creation of a physical inventory doc is required).
1. The error occurs while clearing the inventory posting for the physical inventory document.
2. The surprising factor is the u201CProcess Messageu201D is not processed correctly for the first time.
3. Indeed it is successfully processed without any error if you do process it second time.
Error Log from C054 T-Code.
02.08.2010                                         Dynamic List Display                                                1
Type
Message text
LTxt
Message category: ZHU_CONS ---    Process message: 100000000000000621   "Send to All Destinations" Is Active
Message to be sent to destination:
ZHGI ZPP_0285_XFP_GOODSISSUE Individual Processing Is Active
=> Message will be sent to destination (check log for destination)
Message category: ZHU_CONS ---    Process message: 100000000000000621   "Send to All Destinations" Is Active
Message destination ZPP_0285_XFP_GOODSISSUE triggered COMMIT WORK
Input parameters OK, passed to source field structure
Step 0: Now checking if scenario with HU
Step 2: Scenario with HU, Now checking if HU nested
Step 3: HU nested, checking if HU in repack area
Step 4: HU not in repack area, moving it to repack area
HU moved to repack area, TO number 0000000873
Step 5: Depacking nested HU...
Nested HU depacked, HU pallet n°: 00176127111000461994
Steps 6-7: Moving back HUs to supply storage type / bin...
HU 00376127111000462001 moved back to original area with TO number 0000000875
Steps 6-7: Moving back HUs to supply storage type / bin...
No need to move back HU 00176127111000461994 (not in table LEIN)
Step 8: Checking if HU fully used and quantity matches HU system quantity
HU not fully used but picked quantity > HU quantity: inventory necessary
Step 9: Inventory needed, creating physical inventory document...
Physical inventory document 0000000126 created
Step 10: Adding weighted quantity on inventory document...
Weighted quantity entered in document 0000000126
Step 11: Posting rectification in inventory document 0000000126...
Physical inventory document 0000000126 rectified
Error: rectification for doc 0000000126 not updated in DB!
=> Destination ZHGI ZPP_0285_XFP_GOODSISSUE can currently not process the message
=> Message is not sent to any destination
The errors in SM13 for this contain the program SAPLZPP_0285_HUINV_ENH (creating/changing the HUM physical inventory doc). WM Function module L_LK01_VERARBEITEN is also involved.
From SM13, it displays the following piece of code in include LL03TF2M (read the LEIN table=Storage Units table):
WHEN CON_LK01_NACH.
       IF (LEIN-LGTYP = LK01-NLTYP AND
             LEIN-LGPLA = LK01-NLPLA) OR
              NOT P_LEDUM IS INITIAL.
       ELSE.
Das ist der Fall einer TA-Quittierung wo Von-Hu = Nach-HU ist und sofort die WA-Buchung erfolgt. Dann steht die HU noch auf dem Von-Platz, daher darf hier kein Fehler kommen, sondern es wird ein. Flag gesetzt, daß verhindert daß die LE fortgeschrieben wird.
         FLG_NO_LE_UPDATE = CON_X.
        MESSAGE A558 WITH P_LENUM.
       ENDIF.
Translation in English of the German text via Google:
"This is the case where confirmation of a TO source-HU = destination-HU, and now the WA (Good Issue?)- made book. Then, the HU is still on the From-space may therefore come here not a mistake, but it sets a flag that prevents that the LE is updated."
Thanks and Regards,
Prabhjot Singh
Edited by: Prabhjot Singh on Aug 2, 2010 4:39 PM

Hope you have carried out following things in Production ( Please refer to SAP help before actually doing it in production).
1. Transport the predefined characteristics from the SAP reference client (000) to your logon client.
2. Adopt Predefined Message Categories - In this step, you copy the process message categories supplied by SAP from internal tables as Customizing settings in your plants.

SAVE_TEXT for long error Message not working.

Hi Experts,
I am Using SAVE_TEXT FM to Dynamically Change Long Text for a message.
1. i am able to run succesfully SAVE_TEXT with SY-SUBRC = 0.
2. I can see the entry in STXH.
3. I have also performed COMMIT_TEXT with all the parameters and COMMIT_WORK.
4. I am able to See the changed Text using READ_TEXT FM.
but if i go to SE91 to the message no. and see long text i am not able to see the changed text.
also when change the long text of it in a program and call the error message we should be able to see the changed long text on click of error message in status bar but it shows the same message as in SE91.
Earlier for this Text Object & Text ID in SE75 Save mode was SPACE so i changed the same to Update still its not working.
Following are the details of my code-
REPORT YTEST_MES message-id ZFQM.
parameters : p_text type c.
at selection-screen.
if p_text <> 'C'.
data: HEADER LIKE THEAD.
data: t_lines type standard table of TLINE.
data: ls_lines like line of t_lines.
ls_lines-TDFORMAT = ' '.
ls_lines-TDline   = 'TEST1 TEST2 TEST3'.
append ls_lines to t_lines.
Header-TDOBJECT   = 'DOKU'.
Header-TDNAME     = 'ZFQM093'.
Header-TDID       = 'NA'.
Header-TDSPRAS    = 'EN'.
Header-TDFORM     = 'S_DOCU_SHOW'.
Header-TDSTYLE    = 'S_DOCUS1'.
Header-TDLINESIZE = '72'.
CALL FUNCTION 'SAVE_TEXT'
    EXPORTING
     CLIENT                = SY-MANDT
      header                = header
     INSERT                = 'X'
tables
      lines                 = t_lines
   EXCEPTIONS
     ID                    = 1
     LANGUAGE              = 2
     NAME                  = 3
     OBJECT                = 4
     OTHERS                = 5
IF sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
CALL FUNCTION 'COMMIT_TEXT'
EXPORTING
   OBJECT                = 'DOKU'
   NAME                  = 'ZFQM093'
   ID                    = 'NA'
   LANGUAGE              = SY-LANGU
COMMIT WORK AND WAIT.
message e093 with 'C'    'XXXX'.
endif.
I have tried calling SAVE_TEXT will possible combination's of INSERT = 'X' or space or
SAVEMODE_DIRECT       = 'X' or Both Space or 'X'.
I know i am missing a small thing...but was unable to figure out the same.
Please Help.
Regards,
Akash

Hi Keshav.T ,
Thanks for your answer, but all the above FM u provided-
read_text
init_text
edit_text
Cannot be used as-
Read_TEXT - I want to change Text not read it.
INIT_TEXT- this cannot be used to change texts.
EDIT_TEXT- this function module Opens the Long text screen
                   and we have to manually save it, but i want to save the text automaticaly
                   all this is done using SAVE_TEXT.
Only problem is I am missing something after the call of SAVE_TEXT because text is changed
as i can see that using read_text FM but if i go to SE91 and see long text for the corresponding message no. i cannot see the
changed text done bu SAVE_TEXT.
Please help.
Akash

COMMIT WORK AND WAIT does not work

Hello,
I know this question has been asked many times in various forums. But the fact remains that there is no definitive solution found for this problem which does not involve WAIT UP TO n SECONDS or SELECT until the DB commit has been completed.
We have an IDoc based inbound interface for creating Project Defintion and WBS Elements. Here is how the code looks like in the processing function module:
* Create Project Defintion
CALL FUNCTION 'BAPI_PROJECTDEF_CREATE'
EXPORTING
    project_definition_stru = lwa_proj_bapi
TABLES
    e_message_table         = lt_messages.
* If no errors
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
    wait = 'X'.
* Other code
* Create WBS Element (BAPI could not be used because not all fields are allowed to be updated)
CALL TRANSACTION 'CJ11'
Now while creating the WBS Element, transaction CJ11 returns an error that 'Project does not exist'. This is not correct because the same Project was successfully created in the previous step.
It is clear that the problem is because of the delay in database commits.
This happens only with few IDoc's and not all of them. And of course, the problem does not occur if I induce WAIT UP TO n SECONDS after BAPI_TRANSACTION_COMMIT. But this is not the best practice.
The question is why BAPI_TRANSACTION_COMMIT does not wait even though we are forcing it to?
Thanks in advance
Sagar Acharya

Suhas wrote:
But i am baffled that although the COMMIT has happened earlier why is the data not updated in the DB ?
Well, it's just a [COMMIT WORK|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm] and not a [COMMIT WORK AND WAIT|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm#@@AND%20WAIT@@COMMIT%20WORK@@]. Let me quote the ABAP help:
If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating), but instead is resumed immediately after COMMIT WORK. However, if the addition AND WAIT is specified, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
@Sagar Acharya: Well, I thought you were looking for an explanation why sometimes the project isn't created (and you only had posted coding that showed details for step 1) - I'm trying hard, but my mind reading skills are rather limited yet...
So let's think about step 2 and 3: I assume that you made sure that your coding always references the correct WBS element. Again the commit (without wait) is done already via CJ11 (e.g. check form BUCHEN in SAPLCJWB). I'd expect though that the synchronous update mode should make this work. Since it doesn't, I'd try local update mode, which is what I'd choose in your case anyhow.
Apart from that my mind is pretty blank, except for the usual silly things to check. E.g. are you sure you're coding is correct, you are handling all return messages and log them for inspection later (e.g. application log), you are certain that the WBS was actually created by the same IDoc that throws the fit (and IDoc was not reprocessed), etc.
So maybe somebody else has better ideas...

Lock and Commit work in INBOUND IDOC

Hi Experts,
Problem is about lock and commit work
i need to receive idoc for Good receipt for purchase order.
For one Purchase Order i can receive many good receipt Idoc at the same time and when first came in Lock the Purchase Order and further idoc came after give Errors becouse purchase Order is lock.
Problem is not the serialization (the sequence is correct), but is the lock.
Any idea on how to fix this issue? (maybe there is some std settings??)
Cheers
Boris

Hello Guys
the packetsize is already set to 1 but the problem still again..... and where i can find this setting   "in Customizing choose Engineering Change Management ® Define statuses for master record". ?
Any way i try in function module in inbound to check the lock object with this sample code:
      DO 30 TIMES.
        CALL FUNCTION 'ENQUEUE_EMEKKOS'
         EXPORTING
           mode_ekko            = 'S'
           mandt                = sy-mandt
           ebeln                = goodsmvt_item-po_number
           _scope               = '2'
         EXCEPTIONS
           foreign_lock         = 1
           system_failure       = 2
           OTHERS               = 3.
        IF sy-subrc <> 0.
          WAIT UP TO 1 SECONDS.
        ELSE.
          EXIT.
        ENDIF.
      ENDDO.
but also with this....problem syill again...
thanks
Boris

Reg error in flat file to flat file scenario

Hi techies,
Iam just starting working with XI scenarios.
In base flat file to flat file scenario which is mentioned in wiki.sdn
http://wiki.sdn.sap.com/wiki/display/XI/FLATFILETOFLATFILE
I had completed entire scenario. After generating sender file. Iam getting this error in runtime work bench.
Conversion initialization failed: java.lang.Exception: java.lang.Exception: Error(s) in XML conversion parameters found: Parameter 'CONTACTS.EMP.fieldFixedLengths' or 'CONTACTS.EMP.fieldSeparator' is missing
Please suggest how to resolve this error.
Thanks in advance,
Regards,
Kiran

Hi,
From your error description,
Conversion initialization failed: java.lang.Exception: java.lang.Exception: Error(s) in XML conversion parameters found: Parameter 'CONTACTS.EMP.fieldFixedLengths' or 'CONTACTS.EMP.fieldSeparator' is missing
it is clear that you have missed out either or both the 2 parameters in receiver file adapter content conversion, namely EMP.fieldFixedLengths and EMP.fieldSeparator.
From the example that you followed, use the following values for the 2 parameteres is the output file is a comma separated file:
EMP.fieldFixedLengths: 8,10,10
EMP.fieldSeparator: ,
I have assumed that the lengths of the fields NAME,ADD,MOBILE are 8,10 and 10 respectively. Change them according to your requirement.
Use any other value in place of comma(,) in EMP.fieldSeparator according to the requirement.
Hope it helps you buddy!!!
Thanks
Biswajit
Edited by: 007biswa on Feb 22, 2011 9:25 AM
Edited by: 007biswa on Feb 22, 2011 9:28 AM

Reg. Error in Commit work in FM "SO_NEW_DOCUMENT_ATT_SEND_API1"

Similar Messages

Maybe you are looking for