Skip to Content
Author's profile photo Olga Dolinskaja

Introduction to ABAP Channels

Motivation

Most ABAP applications use polling techniques to achieve an event-driven communication.For pushing an event from an ABAP backend to a browser based user agent like SAPUI5, Web Dynpro, Business Server Pages (BSP) or WebGUI, a polling in multi-seconds interval is frequently used. This is a quite system resource consuming technique. In SAPGUI usually the timer control is used to detect an event in the ABAP backend system. ABAP Channels technology targets to replace such inefficient eventing based on polling techniques through push notifications based on publish-subscribe infrastructure and WebSockets in ABAP.

In which situations you will benefit from ABAP Channels? This blog describes the typical business usage scenarios: Say Goodbye to Polling: Real-time events in ABAP with ABAP Channels.

 

Overview

ABAP Channels infrastructure was delivered with SAP NetWeaver AS ABAP 7.40 support package 2 (SP2) for simple tests and prototyping and released with 7.40 support package 5 (SP5). 
The basic idea of the ABAP Channels (see Figure 1) is the native support of interactive and collaborative scenarios based on event-driven architecture. The scope of ABAP Channels consists of the following communication channels:

  • ABAP Push Channel for bi-directional communication with user agents via WebSockets in ABAP. In the Figure 1 the documents tagged with letter “P” mark the ABAP Push Channel communication paths.
  • Publish/subscribe infrastructure for exchange of messages between either user sessions (Session C => Session A) or user session and user agents
    (Session C => User Agent B) residing on different application servers via ABAP Messaging Channels. In the Figure 1 the documents tagged with letter
    “M” mark the ABAP Messaging Channels communication paths.


Picture6_2.png
Figure1: ABAP Channels support real-time eventing in ABAP

The ABAP Channels support the following use cases:

  • ABAP Push Channel(APC) The WebSocket integration in ABAP.
  • ABAP Messaging Channel(AMC): Eventing framework for message exchange between different ABAP sessions based on publish/subscribe channels.
  • Collaboration scenario: UsingAPC and AMC to push messages from ABAP sessions to WebSocket clients by binding publish/subscribe channels to a WebSocket connection.

http://scn.sap.com/servlet/JiveServlet/showImage/38-89675-431447/amc_apc_collaboration_simple.gif
                                          Figure 2: ABAP Channels use cases in ABAP

General recommendations for usage of ABAP Channels

SAP recommendations for a common programming model for use of ABAP channels are:

  1. Use one WebSocket connection for collaboration scenario
  2. Use SAP Push Channel Protocol (PCP) messaging protocol                                   

Use one WebSocket connection for collaboration

For collaboration scenarios which take use of WebSocket (ABAP Push Channel), it is recommended to share – whenever possible – a single WebSocket connection per client (e.g. browsertab/UI application) for consumption of different types of frequently updated content (feed): e.g. changes applied to a business object, or notification regarding incoming external information (news, weather, sport, chat, activation/deactivation of logs, traces, debugging, etc.).

This is because:

  • This will avoid the unnecessary creation of parallel WebSocket connections for each feed, which is a limited resource at the both communication sides i.e. at the client and the server.
  • Any additional WebSocket connection leads to performance degradation due to WebSocket protocol specific network traffic (e.g. due to keeping alive ping-pongs packages). Furthermore the lifecycle handling of the WebSockets leads to additional complexity at both communication sides.
  • Moreover the situation will worsen when in the UI dependencies between different feeds exist, e.g. because a UI area contains an aggregation of information provided by different feed providers.

Figure 3 shows roughly how the messages are exchanged between an UI application running in a browser and using WebSocket connection (ABAP Push Channel) to ABAP sessions. The ABAP Messaging Channels (AMC 1… 4) are bound to the ABAP Push Chanel (APC). Either the UI Client can act as feed producer sending notifications about business object changes on UI to the subscribed WebSocket clients (Sessions 1…4) or vice versa: ABAP Sessions can publish messages about business object changes to their respective AMCs and they will be pushed by APC to the subscribed WebSocket clients (UI areas of business objects BO 1…4)

Picture5.png
Figure 3: One WebSocket Connection (APC) for collaboration scenario

 

Use common messaging protocol Push Channel Protocol (PCP)

Starting with AS ABAP 7.40, SP05 it is recommended to send and receive messages in ABAP Channels in format of SAP’s own Push Channel Protocol (PCP).

The Push Channel Protocol (PCP) is a message based protocol with message format similar to a HTTP message format.

The proposal of having a common messaging protocol is also valid for most of well-known service oriented infrastructures, e.g. SOA, REST or OData based services. This enables an application developer to publish and consume the services in the same way. Furthermore with this strategy an extension of the provided services is possible, as additional optional fields/metadata can be added to the existing message without breaking the downport compatibility rules.

In context of ABAP Channels the consumption of different feeds by a single WebSocket connection requires a common higher protocol and message type on top of WebSocket for those feeds which are pushed from server. This is necessary because in the WebSocket message handling at the UI client side should be a unique and reliable way to identify the different message types and to assign the appropriate consumer UI area. In worst case if the feeds do not share the same protocol and each feed provider sends different message type, e.g. feed <f1> sends its messages as a kind of custom XML document, feed <f2> as JSON and feed <f3> as binary, it would be hardly possible to process the messages in a simple and reliable way in the WebSocket message handling. 

More about how to exchange messages in ABAP Channels with PCP will be published soon on SCN.

 

Using ABAP Channels

More detailed information about how to use ABAP Channels in the following series of blogs by Masoud Aghadavoodi Jolfaei

For live demonstration and step-by-step implementation guidance take a look at our ABAP Channels Video Tutorials.

For tangible examples in the system see also the blog ABAP Channels Examples.

See also FAQ – ABAP Channels.

Assigned Tags

      31 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Shailendra Karada
      Shailendra Karada

      Nice Article...

      Author's profile photo Former Member
      Former Member

      Very informative blog..
      This will truly reduce the overhead  that exists in polling to check if the object is changed or not.

      Author's profile photo Jibin Joy
      Jibin Joy

      Thanks For Information

      Author's profile photo Former Member
      Former Member

      Nice Blog. Thanks for sharing.

      Cheers,

      Alfred

      Author's profile photo Mathias Bischoff
      Mathias Bischoff

      Hello,

      I hope that this is the right place to post my question?

      We want to create a Socket.IO client Lib to connect from Application Server to another Host that runs Socket.IO Server. Socket.IO is either a Websocket based communication or a XHR Polling based communication (repeating HTTP Requests).

      Well for creating a ressource saving library, websockets are the better to go with. I already saw that there is an interface existing for websocket client connections IF_APC_WS_CLIENT, that probably is similar to the if_http_client interface for HTTP requests.

      As long as I do not find any futher documumentation on this ( IF_APC_WS_CLIENT, CL_APC_WS_CLIENT class and interface ) on SCN or Internet, what do I have to say to our SAP Server Administrator? Which version do I need that he is going to upgrade our Test System. NW 7.5 or EHP 8 (Q1/2016). Will this version contain any documentation (for example RFC configuration SM59) for it, or will just be the plain class without any examples? Will it support only ws protocol or also wss (websocket secure) similar to http and https. I want to avoid that our sytem administrator installs NW 7.5, and we are still missing the needed classes/interfaces.

      Thanks in advance for a response.

      Author's profile photo Olga Dolinskaja
      Olga Dolinskaja
      Blog Post Author

      Hi Mathias,

      for ABAP channels developments SAP NetWeaver AS ABAP 7.4 Support Package 8 (NW 7.4 SP08) is a good starting point, you don't necessarily need NW 7.5. To understand ABAP Push Channel API, which you need to use, please take a look at ABAP Channels Documentation at SAP Help Portal containing also implementation examples or follow the link to the ABAP Push Channel blog linked in this blog above. The youtube video on ABAP Push Channel demonstrates step-by-step the development process.

      I hope this helps.

      Regards,

      Olga.

      Author's profile photo Mathias Bischoff
      Mathias Bischoff

      Hello Olga,

      Thanks a lot. I really appreciate your quick response. ABAP Push Channel blog

      contains a very important note at the end. "A stateful APC communication and also an APC client library are under development." This the one I am looking for :-).

      Does AS ABAP 7.4 Support Package 8 contain this. I want in ABAP to run this JavaScript code. As far as I understand the examples and documentation contain the server side.

      Thanks Olga for your help again in advance.

      Best regards

      Mathias

      Author's profile photo Masoud Aghadavoodi Jolfaei
      Masoud Aghadavoodi Jolfaei

      Hi Mathias,

      the new functionalities, e.g. APC client or APC server steteful, are part of the AS ABAP 7.5 delivery. Just have a look into the APC documention: http://help.sap.com/saphelp_nw75/helpdata/de/99/911508963d452c80d9def3dd864f4f/content.htm?frameset=/de/99/911508963d452c80d9def3dd864f4f/frameset.htm&current_toc=/de/f3/d99aa19ceb44c89907697382aa8726/plain.htm&node_id=3&show_children=false

      Cheers,

      Masoud

      Author's profile photo Mathias Bischoff
      Mathias Bischoff

      Hi Masoud,

      Thanks a lot, this was excactly I was looking for. Great!

      Thanks also to Olga.

      Best Regards

      Mathias

      Author's profile photo Former Member
      Former Member

      Thanks for this blog. Is it possible to use AMC/APC with classical Dynpros?

      Best regards

      Michael

      Author's profile photo Olga Dolinskaja
      Olga Dolinskaja
      Blog Post Author

      Hi Michael,

      you can use AMC in Dynpro-based applications.

      The APC was developed as prototype as SAPGUI Push Channel as well (with AS ABAP 740 SP8 and SAPGUI 740) but not released for productive usage in the SAPGUI. For installation and support strategy of SAPGUI refer to note "147519 - Maintenance strategy / deadlines for SAP GUI".

      Best Regards,

      Olga.

      Author's profile photo Former Member
      Former Member

      "not released for productive usage in the SAPGUI" means it cannot be used by any means?

      Author's profile photo Olga Dolinskaja
      Olga Dolinskaja
      Blog Post Author

      Hi Michael,

      the SAPGUI Push Channel prototype can be used only for test purposes and there are currently no plans for productization.

      I just copy&paste here the step-by-step usage of SAPGUI Push Channel provided by Masoud within the comments to the blog Say Goodbye to Polling: Real-time eventing in ABAP with ABAP Channels

      With SPC it is possible to update SAPGUI controls or the whole SAPGUI screen as well, e.g. after receiving notifications via SPC from different back-end sessions. Furthermore there is a user-specific switch which is off by default to avoid the productive usage by developers and customers. We provided also in the 740 SP8 a simple test report for SPC. If your test environment fulfills the above-mentioned requirements, i.e. using ABAP Application Server 740 SP8 and SAPGUI 740, then you can activate the switch by maintaining the user specific SET/GET parameter “SAPGUI_PUSH_CHANNEL = X”  in the own user profile. For running a test report with SPC just carries out the following instructions:

      1. Activation the SAPGUI Push Channel switch for tests: Choose in the menu bar of a SAPGUI mode the entry “System -> User Profile -> Own Data”. Than enter in the created SAPGUI alternative session the tab “Parameters” and enter the table column “Set/Get parameter ID” the value “SAPGUI_PUSH_CHANNEL” and under “Parameter value” the value “X”, i.e. “SAPGUI_PUSH_CHANNEL = X”.
      2. Now run the test report RS_AMC_RECEIVE_MESSAGE (which acts as a SPC consumer) with the following parameter values:
        • Application ID: ECHO
        • Channel ID: /sapgui/ping
        • Checkbox SAPGUI as consumer: activate
        • Choose “List processing” option

             Additionally execute the report RS_AMC_SEND_MESSAGE in a second SAPGUI    session (to send a message to the SPC session) with the following parameters:

          • Application ID: ECHO
          • Channel ID: /sapgui/ping
          • Message content: whatever you want as text, e.g. Hi there !

               After execution of the RS_AMC_SEND_MESSAGE report you will get a popup      prompted on the first SAPGUI session executing the report    RS_AMC_RECEIVE_MESSAGE without any interaction, i.e. without double clicking the list. This shows how the SAPGUI screen gets updated automatically with the content of the received data using SPC.


          Best Regards,

          Olga.

          Author's profile photo Masoud Aghadavoodi Jolfaei
          Masoud Aghadavoodi Jolfaei

          Hi Michael,

          please also refer to the FAQ – ABAP Channels, section “Can I use ABAP Channels to update SAP GUI frontends directly?“ regarding push message to SAP GUI.

          Cheers,
          Masoud

           

          Author's profile photo Simon Gaudek
          Simon Gaudek

          Hi Olga,

          is it possible, even in ABAP 7.5, to send Messages to specific Users or only to specific channels?

          I would like to implement notifications in UI5 to inform a user about an backend event.

          Greetings

          Simon

          Author's profile photo Masoud Aghadavoodi Jolfaei
          Masoud Aghadavoodi Jolfaei

          Hi Simon,

          to a spcefic channel. You can take use of a channel with activity scope "client" and determine the SHA1 hash value of sy-uname (user name), e.g. based on the function module “CALCULATE_HASH_FOR_CHAR”,  to use this as channel extension id and thus as "target user specific channel" to send a message to a specific user, based on the assumption that the target user accesses a report which act as AMC consumer for the above-mentioned channel.

          Please keep in mind that from security point of view you should use a client specific channel and do not use 1:1 the user id (i.e. sy-uname) as extension but rather apply a canonical transformation, e.g. SH1 hash of user id, to user id to create  the extension id. The security constrains based on the fact, that the AMC channels are used in log and traces (i.e. not only in application server but also in HTTP(S) proxies and reverse proxies and browser logs) if the channel is bound to a WebSocket connection (based on APC application).

          Cheers,

          Masoud

          Author's profile photo Dmitrii Sharshatkin
          Dmitrii Sharshatkin

          Hello Olga,

          What can be the implications of using APC/AMC when events start happening very often? For instance I’m using mixed APC/AMC scenario for informing the technicians about the some errors (e.g. IDOC postings) and, suddenly, the errors start happening very often.

          Any best practice for such scenarios?

          Thanks, Dima

          Author's profile photo Masoud Aghadavoodi Jolfaei
          Masoud Aghadavoodi Jolfaei

          Hi Dmitrii,

          there exists a limitation for the number of AMC channels bound to WebSocket connections which can be adjusted using profile parameter, but for pushing messages to UI (WebSocket client) there exists (more or less) no limits for the number of messages transferred to the WebSocket client. Our tests, partly based on loadrunner, show that it is very hard to reach those (theoretical) limits. Just try to simulate the "heavy load" situation in your development system and if you would see any issues regarding dropping of message just let us know.

          Cheers,

          Masoud

          Author's profile photo Paul Hardy
          Paul Hardy

          Dear Olga,

          I just had a quick look at one of the videos.

          What I am trying to work out is how to code the UI5 JavaScript part to send messages back to the SAP system.

          All the examples on the web (a) send messages out from SAP to UI5 and (b) focus 1005 on the ABAP part and ignore the web part.

          Thus I was happy to see that in the video the front end part was mentioned, however briefly.

          In fact most "old school" ABAP developers would not have much trouble with coding in ABAP, but have a lot of trouble coding in JavaScript, so I wonder why this part is always glossed over by anyone writing on the subject.

          I have taken a screenshot of the ON_INIT method from the video, it is naturally very blurry but I will try to copy it to one of my own applications to see how I go.

          Is there anywhere you can recommend on the web where there is an example of the JavaScript coding needed to establish the web socket connection and send a message?

          The concept is really simple, but the syntax , and the exact place to put the code is not as obvious to ABAP people as it may appear to web developers.

          Cheersy Cheers

          Paul

          Author's profile photo Olga Dolinskaja
          Olga Dolinskaja
          Blog Post Author

          Hi Paul,

          I attached to the blog the example of JavaScript code from the video which demonstrates how to send the messages form UI to backend via WebSocket (see onPost() method).

          Another explanation how to work with WebSockets is in the Masoud's blog ABAP Channels Part 1: WebSocket Communication Using ABAP Push Channels

          Best regards,

          Olga.

          Author's profile photo Former Member
          Former Member

          Hi,
          I am updating a Table using Program - A and using an ALV Report Program - B to display the data of the Table.
          Using message channel sender in Program A when saving in the Table and
          Using message channel receiver in the ALV Report Program B to refresh the ALV.
          I am using statement - Wait for Messaging Channel, but its interrupting the program and no functions can be performed in the ALV during the waiting time.
          As per the example of Chat program, the screen is active even while waiting for messages.
          Can such be performed in the receiver message Program ALV Report B for dynamic refresh ?
          Waiting for an early response.
          Thanks and Regards,
          Satyendra

          Author's profile photo Olga Dolinskaja
          Olga Dolinskaja
          Blog Post Author

          Hi Satyendra,

          please refer for the answer to your question to the FAQ - ABAP Channels, the related question "Can I use ABAP Channels to update SAPGUI frontends directly?".

          Kind Regards,
          Olga.

          Author's profile photo Carol Vega
          Carol Vega

          Great and very useful post !

          Thanks for Sharing...

          Author's profile photo Petr Plenkov
          Petr Plenkov

          Did anyone face the problem with "On hold/Handshake" process status dealing with point-to-point communication? It's very annoying - because I may send like 200 messages with almost no cost and then some message may stuck for like forever holding the main process.

          This behavior is not reliable and prevents me from using AMC in the production mode.

          I'm planning to raise this issue to SAP via support channel - but was just wondering if someone here had similar symptoms and looking forward to hearing how you solved it. Thanks!

          Author's profile photo Frank Radmacher
          Frank Radmacher

          Hi Petr,

          I´ve tested the AMC point-to-point communication using the test reports RS_AMC_SEND_MESSAGE and RS_AMC_RECEIVE_MESSAGE. All AMC messages are delivered immediately. Thus, I cannot reproduce the issue that you´ve reported.

          However, as an ABAP kernel developer I can confirm that every 200th request might be sent synchronously and requests a handshake from the receiving ABAP session, if certain conditions are fulfilled. This is a safety measure to protect the queue of the receiving ABAP session. Usually, you won´t even notice the handshake, as the receiving ABAP session sends the handshake response immediately when it receives the request.

          Therefore, I guess that you´ve implemented a scenario where the receiving ABAP session is busy and cannot consume the AMC messages in time. Of course, this is just a guess.

          I suggest checking whether the receiving ABAP session can consume the AMC messages. Please also notice the following related points of the ABAP Channels FAQ:
          https://blogs.sap.com/2016/10/13/faq-abap-channels/#_Toc570164271
          - Do I have to use WAIT FOR MESSAGING CHANNELS… statement in my application to "pull" for events?
          - When should I use WAIT FOR MESSAGING CHANNELS UNTIL <logical expression> UP TO <seconds> statement?

          Best regards,
          Frank Radmacher

          Author's profile photo Petr Plenkov
          Petr Plenkov

          Hi Frank - thank you so much for so quick response.

          yes - that's what I want to say - that up to some point  it works like instantly.

          But there is a limit ( not obligatory caused by same process ), when AMC is overloaded.

          I honestly don't know - may be it is connected also to ABAP Daemons somehow.

          Look - I have wrote a minimalistic program:

          REPORT ztest_abap_daemon_stress_test.
          
          PARAMETERS p_times TYPE i OBLIGATORY.
          
          START-OF-SELECTION.
          
            TRY.
          
                cl_demo_abap_daemon_broker=>check_daemon( ).
                cl_demo_abap_daemon_broker=>attach_daemon( ).
          
                DO p_times TIMES.
          
                  DATA(lv_index) = sy-index.
                  DATA(lo_message) = cl_ac_message_type_pcp=>create( ).
                  lo_message->set_text( |Stress test message { lv_index } of { p_times } | ).
                  cl_demo_abap_daemon_broker=>send_message( lo_message ).
                ENDDO.
          
              CATCH cx_abap_daemon_error cx_ac_message_type_pcp_error INTO DATA(lo_cx).
                MESSAGE lo_cx TYPE 'I'.
            ENDTRY.

          To run it you need to start demo abap daemon via DEMO_ABAP_DAEMON  program.

          So here is the point - if you run it let's say for 1000 times - it works.

          But for 10000 ( in your case could be a different scale depending on system resources and settings probably ) it holds for a while.

          The point here - we talk about minor delays because this is a demo daemon and message handler is very simple. In our case message handler runs some RAP BO with commit logic and it takes slightly more - so in our system this problem is visible from few hundreds of messages in the queue.

          I honestly don't know - may be is related to the busyness of the abap daemon.

          here is what i see in a log

          DpAmcMsgDispatch: dispatch message to session T47_U6649_M0_I0
          DpSesGetWorkerType: return workerType DIA for T47_U6649
          DpRqSlotAllocate: return slot 600 (3 pending requests)
          DpRqCreate: creating REQ_HANDLER_AMC_MESSAGE request (rq_id 201454, slot 600)
          DpRqCopyDataOnly: copy data of REQ_HANDLER_AMC_MESSAGE request to REQ_HANDLER_AMC_MESSAGE (rq_id 201453   > rq_id 201454)
          DpCaLockBlk: locked ca_blk 505
          ThRqSend: sending REQ_HANDLER_AMC_MESSAGE request with TH_SEND_RETURN
          ThISendRequest: REQ_HANDLER_AMC_MESSAGE (rq_id 201454) from T29_U6644_M0 (user=PPLENKOV    ) to WORKER, thSendType=TH_SEND_RETURN (0x0)
          DpSesGetWorkerType: return workerType DIA for T47_U6649
          RqQQueueGetNumberOfRequests: Queue <T47_U6649_M0> in slot 63 contains 500 requests of type DIA
          DpSesGetTasks: found 500 open tasks for T47_U6649_M0
          ThRqNeedsHandShake: async message limit reached (session/wp=743/743), reset counter, request handshake
          ThGetStrategy (task_switch=0, inline_hold=4, holdWp=0)
          ThrtGetStrategy: abap strategy ROLL / O.K.
          ThGetStrategy: inline hold wp
          ThNewWpStat (task_switch=0, hold=1)
          ThNewWpStat: strategy hold, set WP_HOLD
          ThISendRequest: new wp stat: WP_HOLD
          Address   Offset  Data to WP

          So it seems like there is a certain limit after which it starts asking handshake. But point is - it behaves like syncronous in this case and we are talking about async process. So here is my biggest concern

          it is important to mention here - that it's completely irrelevant which type of communication is used. By default ABAP daemon is always sync, i have tried to extend abap daemon client with kind of attach_async but it gave no results.. 

          AMC + Daemons seems to be a core technology for local events handling in RAP + UCON tracing (RFC, ICF ) so I hope that this technolgoy should be ready for scale. But some local tests show that is not..

           

          What do you think of my concerns? Do you share them?

           

          Thanks!

          Author's profile photo Petr Plenkov
          Petr Plenkov

          I've made a bit more research and now I know that this problem is AMC scoped. There is a program RS_AMC_PERF_LOAD_TEST, which allows to catch the issue instantly. It's enough just to start it with default settings ( broadcast mode ) to observe this On Hold Handshake situation. No daemons is even needed. The situation is visible only when there are active consumers. Just sending AMC messages without consumer is not a problem.

          Author's profile photo Frank Radmacher
          Frank Radmacher

          Hi Petr,

          Thanks for the detailed information. I think, now it is clear that more AMC messages are sent than the receiving session (AMC consumer) can handle. As you´ve already noticed, this is not really an ABAP daemon related issue. And I would say it´s not even an AMC related issue. In general, if you send many messages from one endpoint A to another endpoint B, you must take care that B can process these messages eventually.

          Of course, the ABAP application server tries to take care of its queues a bit in order to protect the receiving sessions and the application server itself from a malicious sender who sends a lot of messages in a loop.

          What happens in more detail is the following:
          First, messages are queued. In general, for each session up to "rdisp/task_limit" (default 1000) requests can be queued until the ABAP session is terminated with a short dump. To avoid this situation, each sender checks whether the task limit of the receiving session has exceeded half of its task limit (default 500). If this is the case, every 200th request of the sender is sent synchronously.
          This is what you can see in the dev trace that you´ve provided:

          RqQQueueGetNumberOfRequests: Queue <T47_U6649_M0> in slot 63 contains 500 requests of type DIA
          DpSesGetTasks: found 500 open tasks for T47_U6649_M0
          ThRqNeedsHandShake: async message limit reached (session/wp=743/743), reset counter, request handshake
          

          Of course, the behavior could be tuned in some way by increasing the mentioned profile parameter. But I don´t think that fixes the conceptional flaw of the application that an AMC sender produces more messages than the AMC receiver can handle in a reasonable time.

          Therefore, I suggest rethinking the AMC message handling of your application. If an AMC message cannot be consumed in time, it is questionable whether sending this message makes sense at all. Also note that for mass data processing inside an ABAP system there are patterns that scale better than sending each entity with its own AMC message. In general, I suggest decoupling the data transfer from the notification. For example, one could let the consumer (e.g., ABAP Daemon) read the entities directly from the DB. Sending the AMC message for the notification of a new entity can be protected by an Enqueue lock, i.e., the receiver (ABAP daemon) holds an Enqueue lock until it is idle, and the sender only send an AMC message for a new item if it gets the lock. An alternative approach to the Enqueue lock may be establishing an additional AMC channel in the backward direction from the receiver (ABAP daemon) to its senders. Then, the receiver (ABAP daemon) could notify the sender if it reaches an idle state and needs notifications. Also, both concepts can be scaled by using multiple receivers (ABAP Daemons) if the operations that are triggered at the receiver itself are the bottleneck.

          Best regards
          Frank Radmacher

          Author's profile photo Petr Plenkov
          Petr Plenkov

          Hi Frank - thanks for such a detailed response. This  kind of message is a great example of why this community is so unique. It's a pleasure to have opportunity to have such a conversation with ABAP stakeholders. Well - that's what I understand too in general that we're dealing with kind of locks. But that's point - now I'm trying to understand what is the principal difference in your scenario:RS_AMC_SEND_MESSAGE + RS_AMC_RECEIVE_MESSAGE. Because there I can send huge number of messages within few seconds and there are no handshakes in the process list.

           

          Author's profile photo Petr Plenkov
          Petr Plenkov

          So actually i went even deeper - I have tried to create a daemon listening to AMC in the identical to RS_AMC_RECEIVE_MESSAGE way and created a handler there ( same as CL_LOGGING_BASE does ). And what an interesting observation - RS_AMC_SEND_MESSAGE triggers Handshake locks. So what seems to be non-locking mode appears to lock the producer sessions. And in opposite a dialog process outside of ADF is capable to handle large amount of messages ( even not point-to-point but via just channel name ).  I'm going to go now more and see how it will behave from the other background processes ( batch jobs and background tasks/bgRFC).

          Author's profile photo Petr Plenkov
          Petr Plenkov

          I also followed your advise - indeed your program works RS_AMC_SEND_MESSAGE + RS_AMC_RECEIVE_MESSAGE. I was able to send within few seconds thousands of messages by dedicated consumer id.

          But somehow it doesn't work if we consume it from the ABAP daemon or from aRFC.

          I keep on my research - may be the dialog process has something else what those sessions don't