Sm58 and RSARFCEX

Hi Guru 's
Can anybody tell me what is sm58 T-code .
I have R/3 , BW and APO system . Both APO and BW system are connected via rfc to R/3 .
I find some old request of last month in error . I dont know what to do with this .
Which tables does this error request get populated.
Also , what is the report  " RSARFCEX ", what does it do and what frequency should we scheduled this report .
Regards
Anthony

Hi Anthony,
transaction SM58 is a report for monitoring the status of transactional RFC.
So with this transaction you can monitor the status of the tRFC communication towards your APO and BW.
The reason why somethimes it happens that you have an entry in that report is that an error happened (you can see the error description by double clicking on the status, tipically SYSFAIL) while trying to deliver a message to the target system.
For example if the user and password specified in the RFC destination are wrong (in transaction SM59) you'll get an error status in SM58.
Once you see an error you can manually restart the execution of the RFC.
Report RSARFCEX is used to automatically restart the execution of messages in error status so you get rid of temporary errors.
The scheduling frequency depends on your requirements but tipically it is scheduled every 5 or 10 minutes.
Regards,
Sergio

Similar Messages

  • IDOC Error in SM58 and Management Console

    Hi Guys,
    Good day!
    I am currently having issues on sending IDOCs to BODS.
    There are instances that an IDOC gets stuck or ends up with an error in transaction code SM58. In transaction WE02, the IDOC is
    successfully processed with status 03. In a set of IDOCs (10 or more), one IDOC is in error in SM58, usually the first IDOC gets the error and the next IDOCs are successfully processed. The error received in SM58 displays the following:
    Error 1: R3RfcClient(DI_CLIENT)ActaIDocFunc::Process()...
    Error 2: CPIC-CALL ThSAPCMRCV no data received
    However, the client interface is active/running.
    In the management console, the error Logs-History displays the following:
    (14.0) 04-08-14 23:32:51 (E) (8060:3868) Unknown: SP(INVOICE_001, ABC:1234)::flowThread() Flow became
    invalid during waiting for request (BODI-300137)
    (14.0) 04-08-14 23:32:51 (E) (8060:9356) Unknown: R3RfcClient(RFC_CLIENT_INTERFACE) ActaIDocFunc::Process()
    encountered processing error for Requeste(15149) (Communication Error. See real time job log for details.) (IDOC 0000001234567890/ABCDE). (BODI-300129)
    For the Real-Time Services log, the following is displayed:
    (14.0) 04-08-14 23:32:39 (E) (70684:47620) RUN-051005: |Session REALTIME_INVOICE|Data flow DATAFLOW_INVOICE|Loader query_IDOC_DETAILS Execution of <Regular Load Operations> for target <IDOC_DETAILS> failed. Possible causes: (1) Error in the SQL syntax; (2) Database connection is broken; (3) Database related errors such as transaction log is full, etc.; (4) The user defined in the datastore has insufficient privileges to execute the SQL. If the error is for preload or postload operation, or if it is for regular load operation and load triggers are defined, check the SQL. Otherwise, for (3) and (4), contact your local DBA.
    (14.0) 04-08-14 23:32:50 (E) (70684:68856) DBS-070401: |Session REALTIME_INVOICE|Data flow DATAFLOW_INVOICE|Loader query_IDOC_DETAILS ODBC data source <ABC\ABC,12345> error message for operation <SQLExecute>: <[Microsoft][SQL Server Native Client 10.0]TCP Provider: An existing connection was forcibly closed by the remote host. >.|<Regular Load Operations>|<IDOC_DETAILS>
    Given this, I would like to ask on how to eliminate this issue.
    Thanks,

  • SM58 and SM59

    Hi All,
    What is the use of SM58 n SM59? How to use these T-Codes effectively ? I wanted to get some info bout Transactional RFC also.
    Thanks.
    Edited by: sap bw on Feb 11, 2008 2:52 AM

    Hi,
    SM58 - Transactional RFC (Remote Function Call). BW uses tRFC for data transmission and this transaction will list all the RFCs associated with a request. You can get details like target system, status, RFC id, etc. so that you can check in BW whether there was any errror with the RFC.
    SM58 is used to monitor the data packets coming into BW from the R3 side or from BW to BW. You can see every data packet through this transaction. So if any data packet is stuck in the source system, then you can basically see that from this transaction and take the necessary action to push it through. TRFC is nothing but Transactional RFC which connects the 2 systems and is used for sending data from one system to other.
    It'll be there for any load, full or delta coming from the source system. You can push them manually by clicking on the data packet and then hitting key F6. you can do that for most of the errors, but for say that the background user password has changed or if the user is locked, you need to change that first then reprocess.
    SM59- During the extraction process a job will run in R/3 side and we could see the status of that job in SM59 like what tables it is accessing and how many records and all
    RFC destination is connection to source system and BW we need to set up this on both the sides.
    Please check this link
    http://help.sap.com/saphelp_erp2005/helpdata/en/78/67ee407552742ae10000000a155106/frameset.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/42/e7a9753c303ee4e10000000a1553f6/frameset.htm
    BW connectivity document
    http://help.sap.com/bp_biv335/BI_EN/BBLibrary/documentation/B84_BB_ConfigGuide_EN_DE.doc
    Hope this helps,
    Regards
    CSM Reddy

  • Getting Error in SM58 and IDX2 while using IDOC from

    Dear All,
    Getting error when trying to send FIDCCP02 Idoc from ECC to PI system.
    "Basic Type 'FIDCCP02' is unknown"
    Getting the same error while trying to import metadata using IDX2 from PI side.
    All connections and distribution model are created.
    Please help
    Regards

    hey,
    I checked all config again but getting error while checking ocnsistency in BDM5 on ECC system(E1Q).
    It is failing when the messge type FIDCC1 reaches PI QA (X1Q) system and the error states
    Message type FIDCC1 is not defined
    Please check last line of below message:
    E1QCLNT001     Checks in own system E1QCLNT001          
         Message type     @08\QCheck OK@     Message type FIDCC1 is defined
         Segment filtering     @08\QCheck OK@     No segment filtering
         Conversions     @08\QCheck OK@     No conversion
         Partner profile     @08\QCheck OK@     Partner profile has been created
                                      @08\QCheck OK@     .....Port PI_QA
              @08\QCheck OK@     .....Port PI_QA
              @08\QCheck OK@     .....Packet size 0001
              @08\QCheck OK@     .....Basis type FIDCCP02
              @08\QCheck OK@     .....enhancement
         Port     @08\QCheck OK@     Port PI_QA : To PI Quality System
              @08\QCheck OK@     .....Port type: Transactional RFC
              @08\QCheck OK@     .....port version 3: IDoc record types from Version 4.0 onwards
              @08\QCheck OK@     .....Logical address (destination) X1QCLNT001
         Logical address (destination)     @08\QCheck OK@     Logical address (destination) X1QCLNT001 is defined
    X1QCLNT001     Checks in partner system X1QCLNT001          
         Check of own logical system     @08\QCheck OK@     Own logical system is X1QCLNT001
              @08\QCheck OK@     Logical system is the same as the target address
                       Message Type     *@0A\QCheck resulted in error@*     Message type FIDCC1 is not defined
    When I am clicking on error it is taking to WE81 on PI side.
    So do I need to add this message type in PI system as it is present in ECC side?
    Thanks
    Edited by: Chanakya Sharma on Dec 10, 2010 12:10 PM

  • Shure SM58 and baggs M1 acoustic guitar pickup

    I have tried to get a 'true' acoustic sound using the above, Using two mono dry tracks, zero settings, I am getting a delayed response signal through my headphones when I play. What have I forgotten to do? I never had a problem with Garageband. I'm new to Logic and one of those guitarists who record dry tracks and adds effects when mixing down, done.

    Try these:
    1. verify if your M-Audio has a zero latency monitoring;
    2. low the buffer size;
    3. disable Logic monitoring.
    cheers
    rob

  • RSARFCEX - Scheduling Error

    Due communication failure tRFC are failed . To reprocess failed tRFC I am using RSARFCEX and scheduling the program as job with the frequency of every 5 min. It does delete the entry from SM58 and shows like it has been processed . But I i checked with the Broker It is not . But when i execute the same program manually ( SE38) . It works perfectly fine . It seems at a glance . There is some issues When I am scheduling the same . Any input is apprciated .
    Thanks
    Sameer

    hi,
    For the R/3 system to identify incorrect calls, it must receive a proper error status for each Oracle Application Server ProcessConnect inbound call. The protocol for all ALE interactions automatically handles the error status; whereas the protocol for RFC will not unless you explicitly select the transactional RFC (tRFC) protocol. This is the same protocol used by ALE. In ABAP, if the keywords "in background task" are appended to the call statement, then the function module is called asynchronously. This has the side effect of selecting the tRFC protocol. The tRFC protocol automatically reports errors. For example, the call to the function module Z_MY_FUNC_MODULE would look like call function 'Z_MY_FUNC_MODULE' in a background task.
    Managing Incorrect Calls
    To list incorrect calls, log on to SAPGUI. Using the R/3 system standard menu, select Tools > Administration > Monitor > SM58 Transactional RFC. Enter your search criteria and click Execute. The list of incorrect tRFC calls appears. On this page, you can delete an incorrect call by selecting a row and clicking Delete Entry. You can also reexecute a call by selecting a row and clicking Edit > Execute LUW. The list contains both invalid ALE calls and invalid asynchronous RFC calls.
    To reexecute incorrect calls in batch, log on to SAPGUI. Using the R/3 system standard menu, select Tools > ALE > ALE Administration > Services > Communication > Transactional RFC > BDA1 Invoke Calls Again. Enter your selection criteria. It is recommended that you unselect the option Currently being processed. As soon as you click Execute, the calls immediately reexecute. For automatic retry, save your selection criteria as a variant. Select Goto > Variants > Save As Variant and give your variant a name.
    Scheduling an Automatic Retry
    To retry incorrect calls automatically, you must schedule a background job. This uses the built-in ABAP program, RSARFCEX. Log on to SAPGUI. Within the SAP standard menu select: Tools > CCMS > Jobs > SM36 Definition. The screen to define a background job appears.
    Enter a new job name, for example, TRFC_RETRY.
    Enter job class C.
    Click Start Condition.
    Click Immediate.
    Select Periodic job.
    Click Periodic values and enter the period.
    Make sure the period is long enough to allow completion of each iteration.
    Click the diskette icon to save the period values.
    Click the diskette icon to save the start time.
    Click Step.
    For the ABAP program name, enter RSARFCEX.
    For the Variant, enter the name of the variant you created on the BDA1 screen.
    Click the diskette icon to save the step.
    Click the diskette to save the background job.
    As soon as you save, the ABAP program runs the job.
    If a call is retried and fails again, it stays in the queue and it is retried at the next iteration.

  • Generating and transferring purchase requisition IDoc

    In ECC 6.0 there exists ALE_PR_CREATE which gave us all the required fields for generating the IDoc that we needed to transfer to our JCo program. Once the IDoc was generated using this program, it's status was set to '30' automatically.
    The next step in order to send this generated IDoc to the designated port was to make use of the standard program RSEOUT00 passing the message type so that it sends all IDocs, of that particular message type (PREQCR and PREQDL in our case) and having a status of 30, to the port, changing the status to 12 once this operation is completed.
    Since it was a standard program , I used the same logic in 4.6C. Unfortunately, the function module ALE_PR_CREATE does not exist in 4.6C.
    The alternative was to use ALE_REQUISITION_CREATE and ALE_REQUISITION_DELETE.
    Why 2 Function modules? Here's why...
    The first function module gave us all the required fields except one - the deletion indicator.
    Keep in mind that this field was also provided by ALE_PR_CREATE in ECC 6.0 system thus eliminating the need to look elsewhere.
    So, to satisfy our requirement of getting the deletion indicator for deleted items of a particular Purchase requisition, we found the second mentioned function module - ALE_REQUISITION_DELETE.
    This threw another problem in front of us...
    This function module gave us only the purchase requisition number, item number and deletion indicator. All the other data fields that we required for our java app to process the IDoc were missing.
    In order to solve this issue, we have designed our program to generate 2 IDocs one after the other. First using ALE_REQUISTION_CREATE and next using ALE_REQUISITION_DELETE in sequence.
    This gives us all the fields.
    The next problem was that the generated IDocs were having the status 03 (Data passed to port. OK.) but the Java application never seemed to receive the generated IDocs.
    A search on SDN led me to check the IDoc queue in SMQ1, a case of stuck IDocs in SM58 and also changing IDoc status in BD75 all in vain.
    Finally, on debugging the RSEOUT00 program, found out that it is checking for the status '30' (IDoc ready to be sent to port) which is hard coded in the program.
    On doing further research on SDN, find some resources that suggested various function modules.
    Tried out all of them one after the other.
    By trial and error, finally stumbled upon the Function Module 'DEQUEUE_ES_EDIDOCS' that acted as a replacement to using the RSEOUT00 program.
    After the IDoc is generated, just passing the IDoc number to this Function module sends it to the port and this was successfully received by our Java app.
    Posting this on SDN for the general benefit.
    Has anyone faced any similar issues? Let us know.

    Hi,
    Im using the non-enjoy  BAPI and BAdI for PR and for deletion the outbound IDoc gets send out all the way but for create outbound IDoc it gets stuck in status 30. I did try the FM that you suggested but doesnt have any effect.
    FMs that is being used inside my BAdI:
    ALE_REQUISITION_CREATE
    ALE_REQUISITION_DELETE
    Thanks,
    Arash

  • Alert in case of errors in XI tx sm58

    Hi,
    we discovered that we sometimes (not more often than once a month) have errors in XI tx sm58, e.g. when a target SAP system has been down and idocs have not been delivered.
    Is there an easy way to monitor sm58 and send e.g. an email in case of errors?
    Thanks,
    Philipp

    Hi,
    May be you can have a check on "ARFCLOG" table so that you can generate the alert.
    for the blocked/Queued IDocs.
    Hope this helps.
    -Prasad Babu.

  • SM58 Transaction Recorded Very Slow

    Dear Experts,
    I have many tRFC in PI system in SM58 with status transaction recorded. This seems to be because there were an unusual data (file to idoc) from 1 interface that suddenly sends more data than usual. This happens at midnight, since then we have a queue at in SM58 with many  transaction recorded (until tonight).
    Strange things is actually that when I try to execute the LUW (F6), the transaction could be processed successfully, even though sometimes after pressing F6, the processing time could take some time (marked by the loading cursor). When the processing time is long, I just stop the transaction, re-open SM58, then the transaction that was executed before will be in the "executing" status and then I execute LUW for the transaction again and it never takes a long time to execute it.
    Trying to execute LUWs and ticking the recorded status would end up no transactions executed.
    Checking in SMQS for the destination, it is rarely that the actual connection reach the maximum connection. Seeing QRFC resource in SMQS, the Resource Status shows OK.
    Going to SM51 then Server Name > Information > Queue Information, there are no waiting requests.
    Actually the transactions are do processed, it just they are processed very slow and this impact to the business.
    What can I do when this happens? How to really re-process those recorded transactions?
    Could this be because the receiver resources? How to check for this?

    Dear Experts,
    According to this link,
    http://wiki.scn.sap.com/wiki/pages/viewpage.action?original_fqdn=wiki.sdn.sap.com&pageId=145719978
    "Transaction recorded" usually happens when A. processing idocs or B. BW loads.
    A.If it occurs when processing idocs you will see function module "IDOC_INBOUND_ASYNCH" mentioned in SM58.
    Check also that the idocs are being processed in the background and not in the foreground.
    Ensure that background processing is used for ALE communications.
    Report RSEOUT00 (outbound)can be configured to run very specifically for the high volume message types on their system. Schedule regular runs of report RESOUT00 it can be run for
    IDoc Type and\or Partner etc..
    To set to background processing for Outbound idocs do the following:
    -> go to transaction WE20 -> Select Partner Select Outbound Message Type and change the processing method from
    "Transfer IDoc Immedi." to "Collect IDocs".
    Reading that explanations, should the setting of IDoc processing to background (Collect IDocs) is done in PI or the receiver?
    If the IDocs is processed collectively, will it make the sending IDoc process faster from PI to the receiver system? What is the explanation that if the IDoc is processed collectively, it would make the IDoc sending to be faster?
    Why should we use RSOUT00 report when we already have SM58, and we can execute LUWs in SM58?
    Thank you,
    Suwandi C.

  • How to get count of transaction entries in SM58 including all the status

    Hi,
    How can we get the count of total number of transactions present in SM58.
    Please help.
    Regards,
    Subbu

    I don't think there is a direct way of doing that. However, you can try running the same query from the selection criteria of SM58 on the ARFCSSTATE table.
    Try activating the SQL trace on ST05 (for your user), run the SM58 and click on "Execute". Stop the ST05 trace and display it. The same query performed by the transaction will be displayed there, allowing you to run it manually and check the number of records.

  • Problem in TRFC queue (SM58) - IDOC2FILE scenario

    Hi,
    I am executing IDOC2file scenario. In the transaction we19, i have successfully posted the IDOC to external system (XI).
    But the iDOC is still in TRFC queue. (SM58 or BD87).
    <b>Recipient details</b>
    Port : RFC in We21.
    Partner No. : XI logical name.
    Partner Type: Logical system.
    <b>Sender details</b>
    Port : SAPBIW
    (This is the confusing part, I was told that first three letters should be SAP and next three should be SID of the SAP system).
    Is this mandatory. But my TRFC (we21 in BW) didn't have any such port, so i created one.
    Partner No. : BIW logical name.
    Partner Type: Logical system.
    I am getting this error in SM58
    <b>Transaction IDX1: Port SAPBIW, client 001, RFC dest contains error.</b>
    Now i want to know what is the problem because of which IDOC is not being to pushed to XI

    Hi,
    go to sm58 and release or delete  that queue, next time idoc will not stuck in  the queue.
    <i><<<Port : SAPBIW
    (This is the confusing part, I was told that first three letters should be SAP and next three should be SID of the SAP system)Is this mandatory</i>
    It is not mandatory, you can leave this option blank.
    Thanks

  • SM58 (transactional RFC)

    Hi,
    In our source system in SM58 (transactional RFC) i am getting the Status Text:                                                 
    User is locked. Please notify the person responsib
    Please advise how to proceed
    Thanks
    Please search the forum before posting a thread
    Edited by: Pravender on Aug 12, 2011 4:09 PM

    Hi
    Thanks for the update.
    I can execute the TCode SM58 and there i can see all the RFC queus are failed becaus of User Locked

  • SC with awaiting approval status and no work item for Approvers.

    Hi Experts,
    We are implementing Classic scenario with SRM7.0 and we are having Application controled Workflow.
    We are fasing issue in workflow. On SC getting ordered the status is showing as awaiting approval and there is no work item found in BBP_PD.
    When we approve this SC in SWO1 then there is no PO getting created.
    If the SC value is less than spend limit we have enabled no Workflow and in that case the approval agent table is showing as System Approver and after SC getting ordered the SC is still with the status Awaiting approval.
    Can any once have an idea how to go about with this issue.
    Regards,
    B.N.Karthikeyan

    Hi,
        Did you check the event linkage in SWE2? what do you see in SLG1? Did activate the task groups 40000003 and 40000007? also check in SM58 and SM21..
    Saravanan

  • SM58 entries processed very slow

    Hi Gurus,
    currently we are facing problems with TRFC queue entries, during sometimes all entries are struck up in the queue and processed very slowly. For that we have scheduled a TRFCs processing job, but still entries are getting process very slow.
    if any one of come across the similar issue, please provide your inputs.
    Thanks and Regards,
    venkat.

    A SAP notes search with keywords SM58 and performance could give you a start.
    For example:
    Note 375566 - Large number of entries in tRFC and qRFC tables
    Note 460235 - tRFC/qRFC: Low-speed processing

  • SM58 - "Function module executed"

    Scenario:  XI  --> R3
    In SM58 I have some messages with status "Function module executed"
    What does this mean? Are the IDocs received succesfully in the target system?
    Best Regards
    Niels Færch

    There is a very good chance that the IDOC has indeed reached the target system...
    Infact we had faced situation like this were we have entires in SM58 in XI (with the same status as what you have)....and the idoc is there in target...
    To confirm that the idoc is there...check the TID in SM58 and make sure there is an IDoc with the same TID....i.e. if you have huge number of IDocs..if you have only very few ..you can easily verify by looking at content in WE02...
    and then in SM58...choose the menu option Edit->Delete Entry
    Thanks.

Maybe you are looking for