Qrfc and smq1

hi experts ,
What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1 ?
regards

hai,
RSA7 DELTA QUEUE MONITOR
qrfc -outbound queue
when the data going the deltra extraction we want to see the process..at the time we using rsa7. qrfc which the going out how many dtas still waiting..that means queues...we find useing this transaction code..
thanks.
if its usefull assign points.
prakasu.

Similar Messages

Urgent(Issue in RSA7 and SMQ1)

We have two data sources 0CRM_OPPT_H and 0CRM_OPPT_I are in RSA7 and
we deleted queues manually for these data source in SMQ1. Whenever we
dochanges to records related to these data sources that changes we can
able to see in RSA3 and Data base tables but there is no change in
number of records in RSA7 and no Queue created automatically in SMQ1.
We reinitialized the data source and scheduled it. We can able to
see records when we do Init scheduling and zero records for Delta
scheduling even after we did some changes in CRM side records. Delta is
not picking up in BI side and we are not able to see that changes in
RSA7 and also SMQ1 for these data sources in CRM side.
We are testing this issue in QA and DEV which are SP14 upgrade
systems. We tested in staging which is SP9 system; here I deleted
Queues related to these data sources (0CRM_OPPT_H and 0CRM_OPPT_I) in
SMQ1 and automatically the data sources deleted in RSA7. We
reinitialized the data source and scheduled it. We did some changes to
records related to these data sources and we can see the entries in
RSA7 and SMQ1.

Whenever you make a change in a Delta Datasource, after you reactivated and replicated in BW, the only way to reflect the changes in the queue is to reinitialize it.
If you're planning to reinitialize, it doesn't have any impact if you delete the specific queue in RSA7... However, it's always a good practice to have those queues emptied before making any changes so you don't leave behind records with errors. But that has to be done before the changes.
Hope it helps.
Regards,
Luis

QRFC and TRFC Difference...

Hello All,
I need some help in understanding TRFC and QRFC in CRM middleware.
Please answer the following to help me in understandin the TRFC and QRFC:
1. During data replication between CRM and R/3, when system will use QRFC and when it uses TRFC... I mean in which scenarios.....
2. TRFC error's can be checked in transaction: SM58... During what context system will create the entry in SM58..
Regards,
Srini.

Hi Srini,
a qRFC is a serialized (queued) tRFC. Technically these two are the same, just that the qRFC makes sure that all predecessors of the contained LUW are already committed.
Data replication via CRM Middleware always uses the qRFC.
HTH
Thomas

Transactions RSA7 and SMQ1

Can somebody please tell me what is the relation between SMQ1 , RSA7 and how this delta system works , are these transactions only for the LO extractions. I have already scanned SDN but am not clear , I am clear that all values entered by user will come in RSA7.

Hi......
Check SAP Note : 380078 'FAQ BW delta queue (RSA7) Questions and answers.........
What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix 'BW, the client and the short name of the DataSource. For DataSources whose name is shorter than 20 characters, the short name corresponds to the name of the DataSource.
For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in Table ROOSSHORTN.
In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there."
Hope this helps......
Regards,
Debjani...........
Edited by: Debjani Mukherjee on Nov 13, 2008 7:33 AM
Edited by: Debjani Mukherjee on Nov 13, 2008 7:47 AM

QRFC and tRFC outbound-queue

in SXMB moni entries,
when the message is
for example inbound: IDOC and outbound: AENGINE, the queue seen is a tRFC outboud-queue,
and when inbound: IDOC and Outbound: PE, the queue seen is a
qRFC outbound-queue
can u explain me why this>?
but nowhere i can see inbound-queues in the MONI. means XBTI* or XBQI*...
can u explain me why?

Hi,
Please see the below link
Eo/EOIO?BE - Queue - ? - /people/sap.india5/blog/2006/01/03/xi-asynchronous-message-processing-understanding-xi-queues-part-i
Please go through these links
For queues in message mapping
/people/venkat.donela/blog/2005/06/09/introduction-to-queues-in-message-mapping
Here are the Queues for Asynchronous Message Processing
http://help.sap.com/saphelp_nw2004s/helpdata/en/7b/94553b4d53273de10000000a114084/frameset.htm
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f078394a-4469-2910-c4bf-853c75674694
Regards
Chilla

The difference between qRFC and tRFC

I am studying RFC now,i don't understand when i should use qRFC or tRFC.can any expert tell me.
thanks

Hi kim,
welcome to sdn.
The qRFC Communication Model
qRFC Properties and Possible Uses
All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start applications in remote systems, and to execute particular functions.
Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both systems involved to be active in order to produce a synchronous communication, the subsequent generations of RFC had a greater range of features at their disposal (such as serialization, guarantee for one-time-only execution, and that the receiver system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.
Communication between applications within an SAP system and also with a remote system can basically be achieved using the Remote Function Call (RFC). Here, the following scenarios are possible:
·         Communication between two independent SAP systems
·         Communication between a calling SAP system and an external receiving system
·         Communication between a calling external system and an SAP receiving system
The following communication model shows what these communication scenarios may look like in reality. The actual sending process is still done by the tRFC (transactional Remote Function Call). Inbound and outbound queues are added to the tRFC, leaving us with a qRFC (queued Remote Function Call). The sender system is also called the client system, while the target system corresponds to the server system.
Scenario 1: tRFC
This scenario is appropriate is the data being sent is independent of each other. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, data is transferred by tRFC, meaning that each function module sent to the target system is guaranteed to be executed one time only. You cannot define the sequence in which the function modules are executed, nor the time of execution. If an error occurs during the transfer, a batch job is scheduled, which sends the function module again after 15 minutes.
Scenario 2: qRFC with outbound queue
In this scenario, the sender system uses an outbound queue, to serialize the data that is being sent. This means that function modules which depend on each other (such as update and then change) are put into the outbound queue of the sender system, and are guaranteed to be sent to the target system one after each other and one time only. The called system (server) has no knowledge of the outbound queue in the sender system (client), meaning that in this scenario, every SAP system can also communicate with a non-SAP system. (Note: the programming code of the server system must not be changed. However, it must be tRFC-capable.)
Scenario 3: qRFC with inbound queue (and outbound queue)
In this scenario, as well as an outbound queue in the sender system (client), there is also an inbound queue in the target system (server). If a qRFC with inbound queue exists, this always means that an outbound queue exists in the sender system. This guarantees the sequence and efficiently controls the resources in the client system and server system. The inbound queue only processes as many function modules as the system resources in the target system (server) at that time allow. This prevents a server being blocked by a client. A scenario with inbound queue in the server system is not possible, since the outbound queue is needed in the client system, in order to guarantee the sequence and to prevent individual applications from blocking all work processes in the client system.
Properties of the Three Communication Types
To help you decide which communication type you should use in your system landscape for your requirements, the advantages of the three communication types are listed below:
       1.      tRFC: for independent function modules only
       2.      qRFC with outbound queue: guarantees that independent function modules are sent one after each other and one time only (serialization). Suitable for communication with non-SAP servers.
       3.      qRFC with inbound queue: in addition to the outbound queue in the client system, an inbound queue makes sure that only as many function modules are processed in the target system (server) as the current resources allow. Client and server system must be SAP systems. One work process is used for each inbound queue.
       The qRFC Communication Model
Purpose
Communication within an SAP system or with a remote system can take place using Remote Function Call (RFC). This enables the following scenarios:
·        Communication between two independent SAP systems
·        Communication between a calling SAP system and an external receiving system
·        Communication between a calling external SAP system and an SAP system as the receiving system
Implementation Considerations
The following communication model shows how these communication scenarios can occur in practice. tRFC (transactional Remote Function Call) is still responsible for actually sending communications. tRFC is preceded by inbound and outbound queues, which have led to the name qRFC (queued Remote Function Call). The sending system is called the client system, and the target system represents the server system.
There are three data transfer scenarios:
Scenario 1: tRFC
This scenario is suitable if the data being sent is not interrelated. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, the data is transferred using tRFC. This means that each function module sent to the target system is guaranteed to be processed once. The order in which the function modules are executed, and the time they are executed, cannot be determined. If a transfer error occurs, a background job is scheduled that resends the function module after a defined period of time.
Scenario 2: qRFC with Outbound Queue
In this scenario, the sending system uses an outbound queue to serialize the data being sent. This means that mutually dependent function modules are placed in the outbound queue of the sending system and are guaranteed to be sent in the correct sequence, and only once, to the receiving system. The called system (server) has no knowledge of the outbound queue in the sending system (client). Using this scenario, every SAP system can communicate with a non-SAP system (the program code of the server system does not need to be changed, but it must be tRFC-compliant).
Scenario 3: qRFC with Inbound Queue (and Outbound Queue)
In this scenario, in addition to the outbound queue in the sending system (client), there is also an inbound queue in the target system (server). qRFC with an inbound queue always means that an outbound queue exists in the sending system. This guarantees that the sequence of communications is preserved, and at the same time the resources in the client and in the server system are controlled efficiently. The inbound queue is processed using an inbound scheduler, which only processes as many queues in parallel as the current resources in the target system (server) will allow, This prevents a server from being blocked by a client.
Features
Features of the Three Communication Types
To help you decide which communication types you need to implement according to your system landscape and your requirements, the advantages of the three types of communication are explained below:
·        tRFC
Suitable only for independent function module calls; the sequence of the calls is not preserved
·        qRFC with outbound queue
Function modules in a queue are guaranteed to be processed only once and in sequence (serialization). Also suitable for communication with non-SAP servers.
·        qRFC with inbound queue
The function modules created in the outbound queue are transferred from the outbound queue to the inbound queue; the sequence of the function modules is preserved. An inbound scheduler processes the inbound queues in accordance with the specified resources. Both the client and the server system must be SAP systems. One work process is used for each inbound queue.
Queued Remote Function Call (qRFC)
Purpose
All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start applications in remote systems, and to execute particular functions.
Integration
In contrast the first version of RFC, synchronous RFC (sRFC), which required both participating systems to be active to form synchronous communication, subsequent generations of RFC now provide a considerably extended range of functions (for example, serialization, guarantee that processing occurs once, and the receiving system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.
Contents:
The information about qRFC is organized into the following main sections, with more detailed subsections:
The qRFC Communication Model
·        qRFC with Outbound Queues
·        qRFC with Inbound Queues
qRFC Administration
·        qRFC Administration: Introductory Example
·        Outbound Queue Administration
·        Inbound Queue Administration
qRFC Programming
·        qRFC Programming: Introductory Example
·        Outbound Queue Programming
·        Inbound Queue Programming
·        qRFC API
For an introduction to the new bgRFC (Background RFC), use the following links:
bgRFC (Background RFC)
·        bgRFC Administration
·        bgRFC Programming
Using Asynchronous Remote Function Calls
Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user does not have to wait for their completion before continuing the calling dialog. There are three characteristics, however, that distinguish asynchronous RFCs from transactional RFCs:
·        When the caller starts an asynchronous RFC, the called server must be available to accept the request.
The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server.
·        Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system.
·        The calling program can receive results from the asynchronous RFC.
You can use asynchronous remote function calls whenever you need to establish communication with a remote system, but do not want to wait for the functionu2019s result before continuing processing. Asynchronous RFCs can also be sent to the same system. In this case, the system opens a new session (or window). You can then switch back and for between the calling dialog and the called session
To start a remote function call asynchronously, use the following syntax:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION ...
EXPORTING...
TABLES   ...
EXCEPTIONS...
The following calling parameters are available:
§         TABLES
passes references to internal tables. All table parameters of the function module must contain values.
§         EXPORTING
passes values of fields and field strings from the calling program to the function module. In the function module, the corresponding formal parameters are defined as import parameters.
§         EXCEPTIONS
See Using Predefined Exceptions for RFCs
RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM routine to receive the results of an asynchronous remote function call. The following receiving parameters are available:
§         IMPORTING
§         TABLES
§         EXCEPTIONS
The addition KEEPING TASK prevents an asynchronous connection from being closed after receiving the results of the processing. The relevant remote context (roll area) is kept for re-use until the caller terminates the connection.
Transactional RFC (tRFC)
Transactional RFC(tRFC, previously known as asynchronous RFC) is an asynchronous communication method that executes the called function module just once in the RFC server. The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID).
If a call is sent, and the receiving system is down, the call remains in the local queue. The calling dialog program can proceed without waiting to see whether the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.
tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls
·         are executed in the order in which they are called
·         are executed in the same program context in the target system
·         run as a single transaction: they are either committed or rolled back as a unit.
Implementation of tRFC is recommended if you want to maintain the transactional sequence of the calls.
Disadvantages of tRFC
·       tRFC processes all LUWs independently of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.
·       In addition, the sequence of LUWs defined in the application cannot be kept. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later
thanks
karthik
reward me if usefull

Relation between qRFC and SXMB_Moni tables.

Hello Experts,
I would like to know if there exists any rerference OR any link between the qRFC tables (TRFCQOUT / TRFCQIN) with the backend master tables of SXMB_MONI (SXMSPMAST, SXMSPERR, SXMSPHIST) ETC.
This would give me an idea whether I can fetch out the niche details of the records/messages stuck in qRFC from SXMB_MONI.
Kindly advice.
Thanks in advance,
Elizabeth.

Hi Elizabeth,
Check this recent blog..may be useful to you
SAP XI/PI: Alerts for Queue Errors
/people/santhosh.kumarv/blog/2009/05/19/sap-xipi-alerts-for-queue-errors
Regards,
Sunil.

Clearing of qrfc and trfc tables c

Hi all
we planned to have a bi system
created a client and defined rfc's from r/3 system
no we stoped the bi project...removed client for bi
but the rfc's are still there...so the rfc tables grew up huge
How to clear those RFC tables
And how delete the defined RFC's
thanks in advance
jameel

Hey Jameel,
Those queue saves the information that has changed in the R/3 system,
this is done in order to move the "delta changes" from R/3 to BI.
They are created by customization changes,
and every relevant change in the R/3 (of the object that is being inspect)
would create a record in the queues.
If you would schedule the relevant extractors in the BI
they would read this information and the queues would be empty.
if you don't want to transfer this information to the BI,
than you will have to disable the delta queue in the customization,
and delete those queues.
(if you will only delete the queues without changing the customization
than they would re-create).
About the trfc,
I don't know if they are relevant,
please write more information (what is the destination of the TRFC, what are the functions and the error messages)
p.s
this is a BI questions

How to debug qRFC and Trfc.

Hi All,
how to debugging asynchronyos finction module and Transactional function module when call in Background?
Regards,
Anuj Jain

Hi Anuj,
In transaction SM50 (process overview), you can select a background process and choose Program/Mode -> Program -> Debugging from the menu.
Debugging TRFC
1. Go to the program 'ZREPORT' and go to the CALL FUNCTION 'ZFUNCTIOn' IN BACKGROUND TASK .
2. Keep breakpoint in 'ZREPORT' just before the CALL FUNCTION start .
3. when you reach the breakpoint, Go to menu -- > Settings-> Display/Change debugger settings-> select the flag "tRFC (In Background Task): Block Sending".
4. Execute SM58, Select the background task, and choose menu --->edit -
>debug LUW, the "background task" will start and the debugger will stop at the FM.
Let me know If any further queries
Edited by: Raj on Jul 27, 2010 1:07 PM

Not getting entries in SMQ1 and SMQ2

Hi,
I have implemented the concepts said in the below said blog.
/people/community.user/blog/2006/11/04/how-to-serialize-idoc-xml-messages-fed-into-xi
Still I'm not getting the entries in SMQ1 (R/3) and SMQ1(XI) systems.
Can any one tell me the problem in my case?
Regards,
Thiyagu

Hi,
>>>How to bring entries in SMQ1(ERP)? Currently I could see Queue name
as SAP_ALE_MYNAME in WE05(in help dialog box).
what can I suggest...
you wouldn't happen to have one of those:
www.sap-press.com/product.cfm?account=&product=H1935
queued IDOCs described in both ways XI - ERP and ERP - XI
with screenshots in my book
but basicalls you just need to specify queue name in WE20
and in receiver adapter case additionally queue processing in IDOC channel
that's all there is
>>>And I am using qRFC for this scenario.So, how can i see entries in SM58?
this was just to check if you actually configured if correctly and we're
talking about the same thing
Regards,
Michal Krawczyk

Creating filters for tRFC and qRFC (SM58).

Hi All,
I am trying to create filters for qRFC and tRFC as per OSS note 441269 - Setting up tRFC/qRFC monitoring in the alert monitor. When I try to create/copy owner I am getting error "_not in name space_" in task bar when I try to save the changes, I tried all kinds of naming convection still unable to proceed. Pls tell me how can I resolve this issue.
System:-
Kernel version 700
Support pack 13
Regards,
kurma

Hi Jordan,
We used to 'reorganize' the tRFC/qRFC LUWs via sm58.
Your found note is ok and try to refer some other notes as well.
Note 375566 - Large number of entries in tRFC and qRFC tables
Note 760113 - Delete unprocessed LUWs in the qRFC
Following similar thread might also help -
how to delete error entities in TRFC queue to clear stuck
Thanks

Sysfail status in SMQ1

Hi
I have sysfail error in tRFC and qRFC (SM58 and SMQ1) Error message with function module not found and exception raised .Scenario is from ECC-XI-Third party system.
Checked for dumps in SAP XI where in I could get the following message " Error in ABAP Program "SAPMSSY1"and the program is terminated Probably due to an error in program .this is a standard Program and moreover this interface has run successful till april end
Please let me know your suggestions to clear off the sysfail status

Hi
check the reply of Rob at this thread regarding error with SAPMSSY1 program
Re: ABAP statement RSYN
Regards
Abhishek

SMQ1 & SMQ2 Monitor

Hi Friends,
I know that SMQ2 ia a inbound queue and SMQ1 is a outboud queue but wanted to know where this queues are present exactly and Purpose
I guess SMQ2 is the first step in IE after AE forwards the PI SOAP Message and before the Pipeline steps.
Once Pipeline completes the Call Adapter Step then message goes to Adapter through SMQ1. Please clarify
Regards & Thanks ,
Manikandan

>>when we say outbound (SMQ1) it mean messages are incoming to IE of PI( i.e Sender System->AE->IE)
AFAIK ...the PI XML (from the sender system) message is first placed in the inbound queue after that logical routing and splitting of messages will take place, then the message is placed in the outbound queue (mapping and technical routing will take place) and once all the pipeline steps executed messages from the outbound queue is assigned to the receiver of the message through an adapter(optional)...
XI Asynchronous Message Processing: Understanding XI Queues -Part I
What is the different qRFC outbound and qRFC inbound Queue ?

Check status qrfc BBP_EXTREQ_TRANSFER

Hi,
How do I check the status of the queue BBP_EXTREQ_TRANSFER?.
Can you help me indicating function module or tables?
Thank
Best regard
Alessio

Hi
Please go through this ->
Function Module - BBP_EXTREQ_TRANSFER calls BBP_BC_EXTREQ_INB on SRM side. This function module calls BAPI_SCEC_CREATE.
Program BBP_EXTREQ_TRANSFER on backend side do the following:- load a local stored copy of transfer table EPRTRANS
- create a package from the transfer table without breaks with one PR
- enqueue the corresponding EBAN entries
- transfer the package <-- in this perform we have BBP_BC_EXTREQ_INB and BAPI_SCEC_CREATE function module.
- dequeue the package
Before call BAPI_SCEC_CREATE, program checks if the incoming requirement is arleady existing, derermine limit positions, fill partner table in "i_bup" structure, check category if we don't have product id, pricing for IPC etc.
This information are on SRM side, maybe that's why backend system don't call BAPI_SCEC_CREATE function module directly.
Related links ->
Note 1027506 BBP_EXTREQ_TRANSFER: ANORETRY for PR with different vendors
SRM Function called by BBP_EXTREQ_TRANSFER
Check if external profile is flagged (EBAN-EPROFILE = X) for those PRs which are in EPRTRANS.
Also check if RFC connection is OK between R3 and SRM and RFC user is same as maintained in Entry channel in SRM. RFC user should be service user.
So that temporary problems (for example an external request which is locked in the SRM server) do not have the effect that the qRFC comes to a permanent standstill, you can make sure that the transfer of the purchase requisition is started by the system again. For detailed information on this, see the SAP help for the qRFC in the 'Administration of the outbound queue'. This is only a summary:
Use Transaction SMQS to register the RFC destination which is used for the outbound queue.
Use Transaction SM36 to schedule program RSQOWKEX. This program makes sure that possibly hanging queues are triggered again.
In addition, you have the option to monitor qRFC using the Alert Monitor. For more information on this, see the SAP help for the Alert Monitor under 'Special monitoring functions of the Alert Monitor -> Monitoring qRFC and tRFC calls'.
See SAP OSS Notes ->
Note 650333 - Hanging qRFC after transfer of Preqs to SRM
Re: BBP_EXTREQ_TRANSFER fails if SMQ2 or SMQ1 Queues have errors
BBP_EXTREQ_TRANSFER error:Entries stuck in queue
Which SRM version are you using ? Do let me know.
Regards
- Atul

Mail sending when QRFC is blocked

Hi ,
The requirement is that i need to send mails to certain people when the QRFC queue ( SMQ1 ) is blocked .
The idea is to send a mail when we have 10 messages awaiting on the corresponding queue.
Please let me know if this can be achieved.
regards

Other way..just to tell you
Create another task in approval process which will send the email to requester and attach it with Reject Response of Approve Task in task to generate mapping.

Qrfc and smq1

Similar Messages

Maybe you are looking for