Cross-Session PUBLISH and SUBSCRIBE¶

• Cross-Session PUBLISH and SUBSCRIBE
  • Introduction
  • 4GL Usage
  • Javascript Usage
    • Introduction
    • Details
    • Hotel GUI Examples

Introduction¶

Due to the nature of how client processes are created (as standalone OS processes), cross-session messaging is not supported in OpenEdge, without using sockets, web services or other high-level mechanisms.

In FWD, this is can be supported naturally, as each client exists as a thread in the FWD server running your application. For this reason, the syntax for the SUBSCRIBE and UNSUBSCRIBE can be extended, so that a certain FWD client can listen for published notifications from any client running in the same FWD application server.

In FWD, the current named events support is implemented as an in-session dispatching mechanism that directly calls the subscribed internal procedures. This exactly matches the 4GL approach. There is no event queue involved in this solution. Since everything in the converted 4GL is single-threaded, the event does not need to be queued, the subscribed procedures are just synchronously invoked and the publish does not return until after all subscribers are complete.

Adding cross-session publishing means that the remote session must delay the execution of the event until is in such a state that it can process it synchronously, as by nature this cross-session publish is completely asynchronous. When publishing a global event, FWD will look into the local subscriptions (for the current client) and in all other clients subscribed to this event, and execute the subscriber's procedure. For non-local subscribers, the invocation of the event's procedure will be delayed until the subscriber will be in such a state that it can process events. This requires that the client is in an event processing loop (like WAIT-FOR) or PROCESS-EVENTS statement is executed. This published event will be picked up and processed the same as any other asynchronous event in 4GL (like socket events).

At this time, there is no support for named events that cross FWD server boundaries (more than one FWD server, each running in a different JVM). #4285 is the task which will explore this idea.

4GL Usage¶

The syntax for the SUBSCRIBE and UNSUBSCRIBE was extended in FWD with the GLOBAL keyword. For SUBSCRIBE, this is used as an alternative for ANYWHERE and publisher's handle option:

SUBSCRIBE [ PROCEDURE shandle] [ TO ] evt { IN phandle | ANYWHERE | GLOBAL } [ RUN-PROCEDURE proc ] [ NO-ERROR ]

For UNSUBSCRIBE, this is used as an alternative for the publisher's handle option:

UNSUBSCRIBE [ PROCEDURE shandle ]  [ TO ] { evt | ALL } [ IN phandle | GLOBAL ]

When the GLOBAL option is used, the ANYWHERE mode is assumed - as the subscriber doesn't know who will be the publisher.

For the PUBLISH statement to be able to notify subscriptions from other FWD clients, the GLOBAL option must be used, too:

PUBLISH evt [ FROM phandle ] [ GLOBAL ] [ (p1, p2, p3, ...) ]

Without the GLOBAL option, PUBLISH will notify only local subscriptions; otherwise, the cross-session global subscriptions will be notified too, beside the local ones.

A simple client listening for events published by any other FWD client:

procedure proc0.
   def input param ch as char.
   message ch.
end.

subscribe procedure this-procedure to "global-evt" global run-procedure "proc0".

on "a" anywhere do:
   unsubscribe procedure this-procedure to "global-evt" global.
end.

wait-for close of current-window.

This will receive notifications from any publish "global-evt" global. statements executed by any other FWD client, running in the same FWD server as the subscriber, or from any publish "global-evt". statement executed by the FWD client where the subscription was registered.

As the publisher can pass arguments to the subscriber's procedure, there are some limitations to how they can be used:

• object, blob, memptr, handle, comhandle, buffer, widget or buffer field parameters are not supported, as these are inherently coupled with their instantiating client.
• only INPUT parameters are supported, as any OUTPUT or INPUT-OUTPUT values can not be transferred back to the publisher.

This argument validation is done at the publisher's side - any mismatch in the above is a programming error and will QUIT the FWD client. Note that this validation is performed only when notifying other FWD clients - publish to local subscriptions will work the same as 4GL, even if GLOBAL option is used.

If the arguments pass this publisher-side validation, then the subscriber receives an event which will let him invoke its subscribe procedure - any further argument validation (like datatype, number of arguments, etc) will be done at the subscriber's side.

Javascript Usage¶

Introduction¶

The embedded mode web client provides a Javascript (JS) appserver client that allows "up calls" (from JS to converted code) and "down calls" (from Java code to JS). This provides a unique new capability for integrating JS and converted 4GL applications. As an added feature, the JS client can participate in named events processing (both publish and subscribe). This participation can be for cross-session events or for session-local events.

Details¶

TBD

Hotel GUI Examples¶

The following are example use cases from the Hotel GUI project.

---

© 2017-2019 Golden Code Development Corporation. ALL RIGHTS RESERVED.