Into ABAP channel collaboration, trying to implement 4 scenarios, all of them using PCP protocol, with the help of some really good posts. First two are as provided by the authors, only changes done are relevant to the conversion of the channel from text to PCP
Websocket call from SAPUI5 client, response from backend
Based on ABAP Push / Messaging Channel and SAPUI5 Demo Application, it works fine
Backend communication
Based on https://blogs.sap.com/2014/03/26/abap-channels-part-2-publish-subscribe-messaging-using-abap-messaging-channels/, works fine as well
Here's the AMC channel configuration with both scenarios working (class for scenario 1, reports for scenario 2):
Having the first two working, tried combining them
Message via websocket from the client, delivery to SAP session
Worked just fine (I sent the message from SAPUI5 client and it was received by the GUI backend session), as soon as I removed the APC Channel receiver class, new config below
Message from the backend, delivered to SAPUI5 client (actually, the other 3 served only to reach here)
The idea behind it is removing the report receiver from the authorized programs tab and replacing it again with the APC receiver class, only this time defined as "receive via session", so I can receive the message from the sender report and forward it to the client. Calling SAPUI5 application, connection with APC channel opening as expected, calling backend report, message gets sent correctly by the sender application (sy-subrc = 0, no exception) but seems to go nowhere as a) nothing appears in the client and b) (the most important) break-point inside the on_message method of the APC class is not hit (method not called)
Provided that all other 3 scenarios are working fine, is there something I miss / a specific point that I should have a look or have I understood things completely wrong and scenario 3 works "incidentally"? Scenario 4 AMC configuration below.
Did you bind the Push Channel to the specific APC Channel?
METHOD if_apc_ws_extension~on_start.
TRY.
* bind the WebSocket connection to the AMC channel
DATA(lo_binding) = i_context->get_binding_manager( ).
lo_binding->bind_amc_message_consumer( i_application_id = ‘YAMC_TEST’
i_channel_id = ‘/ping’ ).
CATCH cx_apc_error INTO DATA(lx_apc_error).
DATA(lv_message) = lx_apc_error->get_text( ).
MESSAGE lx_apc_error->get_text( ) TYPE ‘E’.
ENDTRY.
ENDMETHOD.
Related
Managed to get a start with APC Channels, connect from a small sample SAPUI5 app and get messages back, so far so good. Exercise now becomes more interesting, I want to do AMC, send a message to my channel for forwarding to other users who run another instance of the same SAPUI5 app and each of these users receiving only their own messages based on the SAP User ID (that can be part of the message). Been through this really good stuff below:
ABAP Channels Part 3: Collaboration Scenario Using ABAP Messaging and ABAP Push Channel
ABAP Push / Messaging Channel and SAPUI5 Demo Application
If I got things right reading these two, I can combine APC and AMC channels and consume messages I send to the AMC by using WebSocket class methods in SAPUI5. What I don't get is how I can redirect the result to another user. I was thinking that maybe this can be done by using dedicated channels per user (as written above, talking about internal application) in the AMC channel list.
a) is the above assumption right?
b) Can this be done?
c) If the above can be done, can I go even further by (I have no idea how to do that) retrieving client browser sessions for the user (in case there are more than one) and send the message only to one of them?
I'm trying to build a entirely contained trading simulator using quickfix/J. The systems ought to consist of 2 client applications (a market/exchange and a broker) as well as a router (server/acceptor). In particular I'd like to know:
Client-Client communication
How the two clients can communicate to each other, but the server handling all the messaging logic, ie. messages should go through server and it should decide where and how to forward messages. I ought to be able to pass a targetID in FIX message, and the server app should handle routing to desired client.
Multiple clients on same port
Have multiple clients connected on same port but messages should only go to a particular sender comp Id ie. clients should not be privy of communication from other clients.
I've already set up the acceptor, and 2 clients. I know I could do this programmaticaly using plain old Java but I'd like to leverage the quickfix library and would like a relativly out of the box solution.
MVP: client (broker) sends fix message through the acceptor(router), message is processed and forwarded to a particular market, market recieves message through server and does some business logic, market sends fix message back to client through acceptor.
ps: I like the quickfix library but I'm very flexible if there any other library/languages you'd recommend
Short answer: QuickFIX/J (as far as I can tell similarly QuickFIX or quickfix/n) will not route messages based on tags. This has to be implemented in your application code.
Edit: with regard to your second point. There is no problem having your FIX server listening for multiple FIX connections on the same port (This applies for QuickFIX/J and I guess also the other language variants.) Sessions are addressed via the SessionID so it is ensured that only the correct FIX Session gets its messages.
I've never done a notification service on web client and I just would like to know what is the most common pattern.
Like if the server has to push the client or if it's the client which needs to get the server info every minutes for example.
Or if there is another pattern.
There are multiple ways to implement push notifications:
HTTP Long Polling : The client initiates a request. The server checks if it has any new notifications. Irrespective of whether or not it has new notifications appropriate response is send and connection is closed. After time X client initiates another request (+ Very easy to implement - notifications are not real time. They depend on X since data retrieval is client initiated. As X decreases overhead on server increases )
HTTP Streaming: This is very similar to HTTP Long Polling however the connection is not closed. The server sends chunked response. So as soon as server receives new notification that it wants to push it can simply write to the socket. ( + lower latency than long polling and almost real time behaviour / overhead of closing connection and re opening reduced - memory usage client side keeps on piling up / ugly hacks etc )
WebSocket: TCP based protocol provides true two way communication. The server can push data to client any time. ( + ve: true real time - some older browsers dont support it ). Read more about it WebSocket.org | About WebSocket
Now based on the technology stack there are various solutions available:
(A) Nodejs : the cross-browser WebSocket for realtime apps. ( does heavy lifting for you. Gracefully falls back in case websocket is not supported )
(B) Django : As mentioned previously you can use signals for notifications. Also you can try django-websocket 0.3.0 for supporting websocket
(C) Jetty / Netty and Grizzly (Java based) : All have websocket support
from link
This depends on what web framework you use. With a modern framework like meteor, it's very easy for the server to push notifications to clients, and many kinds of display updates can happen automatically, without having to construct a notification mechanism to take care of them.
Have a look at the two Meteor screencasts listed at http://meteor.com.
i have created a metro style datagram server and a client using Windows.Networking.Sockets. i am doing code in c++
Than i tried to connect and send data from client to server.
but the problem i am facing is that,
as windows metro application is totally asynchronous,my app starts to send data before connection being completed.
i want an approach through which my send function will send data after the connection completed.
msdn has provided a sample code for client server but they use a button to send data which takes time to operate meanwhile the connection is completed.Thats why the application runs well.
but i am trying to do client server communication in the main code without using send Button.
Making some assumptions here b/c you didn't provide any code, but you should use the continuation of your DatagramSocket.ConnectAsync create_task. If you put the send data in the task::then, you will not have a problem with the async nature of the call. See this article on dealing with async in C++ Windows 8 apps. Lots of great examples here as well.
We're using GWT Atmosphere to send strings from the server to the client and it works quite well.
However, we would like to send whole entities from the server to the client, serialized by the GWT RequestFactory. Without the need for a request by the client!
So I tried working with SimpleRequestProcessor#createOobMessage(domainObject) and sending that payload to the client. Computing the payload works.
I would then decode that message using AutoBeanCodex#decode and read the domainObject as the correct EntityProxy from the invocation list of the ResponseMessage - however when I do so, it requires some sort of serverId being set to proceed in AbstractRequestFactory#getId (around line 260: assert serverId != null : "serverId")
Any advice on how I can decode a Proxy payload without a request being sent by the client?
Update
The use case for this question is chat-like communication. The client doesn't request the messages from the server but instead will be notified of new messages. And we'd like to include the messages and info on who's sent the message in the notification payload. Since we're using RequestFactory in our project anyway, we want to take advantage of having set up all the Proxy wiring and now simply push the relevant object graph to the client.
Why are you trying to serialize RF messages and send them just as entities? RequestFactory is much more than justa way to send data over the wire - it has at least three different kinds of messages that can be sent from the client to the server: create instances, call setters, and invoke service methods. Based on what happens on the server, not only can data be returned to the client, but messages about what changes were made and if those setters made changes that are not valid under the JSR303 rules.
Are you trying for a simpler, interface way of describing, sending, and receiving entities? Or do you actually want the RF wiring on both client and server so you can batch requests, refer to EntityProxyId instances and have the client only send diffs?
If you just want simpler object declarations, try just using AutoBeans and the AutoBeadCodex you have already looked at - you'll be able to create and marshal instances on both client and server easily, and you can pass them as strings over atmosphere's transports.
If you actually want RequestFactory, but running over something other than AJAX, there are other options. Rather than sending/receiving strings through Atmosphere (which I believe is intended to provide push support for RPC calls), consider using that underlying push layer to implment a new request transport in RequestFactory.
com.google.web.bindery.requestfactory.shared.RequestTransport can be implemented (see com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport for the default AJAX version) to use any communication mechanism you would like - and to build the server, take a look at com.google.web.bindery.requestfactory.server.RequestFactoryServlet for what actually must be done to push messages through the Locator, ServiceLocators, etc.
If you really want to use Atmosphere and RF, then consider building a RequestTransport that wraps a simple Atmosphere interface to call to the server with the string - the cometd/websocket calls will already be taken care of for you, and you'll just have to translate the string message into invocations (again, see how RequestFactoryServlet does it).