Pass parameters
- Last Updated: August 7, 2023
- 3 minute read
- OpenEdge
- Version 13.0
- Documentation
The publisher can pass parameters in the same way as for a RUN statement.
Ordinarily, any such parameters are INPUT parameters so that the
publishing procedure can pass one or more values into each subscriber.
INPUT parameters are the norm because the publisher normally does
not want to know the specifics of who the subscribers are and therefore is unlikely to
be interested in output from them. If the publisher wants to get a specific response
back, then it is better to use a RUN statement with a known procedure
handle to run it in.
In particular, an OUTPUT parameter is almost always a bad idea because
its value is received only from the last subscribing procedure to execute. If there are
multiple subscribers, the OUTPUT parameter returned by the rest of them
is discarded. Since there is no way to determine which of multiple subscribers will run
last, this is not a reliable or useful mechanism.
On the other hand, there are times when it can be useful to pass an
INPUT-OUTPUT parameter. In this case, each subscriber in turn
receives the current value of the parameter and can act on it and modify it. The next
subscriber receives the modified value and can modify it further. Finally, the publisher
receives it as output from the final subscriber and can see the collective result. This
is useful in cases where all the subscribers need to contribute something to a final
total, perhaps adding a value to the current value of the parameter or appending
something to the end of a delimited list. The publisher then sees the result of all the
calls. Again, there is no determined order for the subscribers to be called, but if the
order of execution is not important, then an INPUT-OUTPUT parameter is
sometimes useful.
RETURN statement
that is received by the publisher as the RETURN-VALUE just as if the
publisher had used a RUN statement. Again, there is no way to know
which subscriber will be the final one called, so each subscriber could append text to
the existing RETURN-VALUE in a way similar to using an
INPUT-OUTPUT parameter in a form such as the one in the following
example. In this code, the RETURN statement appends the value of the
local CHARACTER variable cMyIdent to the current
RETURN-VALUE:
|
Each subscriber can see the value returned by the previous subscriber in its
RETURN-VALUE. If this is the final statement in each subscriber’s
internal procedure, then the publisher can look at the value of
RETURN-VALUE and see all the accumulated values of
cMyIdent for all the subscribers.
The PUBLISH statement always executes NO-ERROR. If
there are no subscribers, no error message results. If one or more subscribers have a
parameter list that does not match the parameters in the PUBLISH
statement, then those subscribers do not receive the event and, likewise, no error
results. For this reason, it is important to make sure that subscribers have the proper
calling sequence. Otherwise, their procedures will not be run and it might not be clear
to you why the PUBLISH statement seems to have failed.