I'm trying to use the bpel extension for eventhandling under the soa suite 11g ps3. I'm trying to subscribe to an event from the event delivery network but I get an error.
That's the code:
<eventHandlers>
<onEvent bpelx:eventName="ns4:discountEvent" variable="discEvent" >
<scope name="Scope1">
<sequence name="Sequence1">
<exit name="Exit1"/>
</sequence>
</scope>
</onEvent>
</eventHandlers>
The compiler is giving me the following error:
Error(52): Activity <bpel:onEvent> must have "element", "messageType" attribute present.
I can't find any information on using the extension in an "onEvent" activity.
Any help appreciated!
Thanks, Chris
Event handlers work slightly different than other interaction activities. While receive, invoke etc. work on previously defined variables, the event handler defines its own variable which is visible in the scope of the onEvent's child activity. In order to give this variable a type, either a messageType or an element needs to be identified to be the declared type of the variable. This is why element or messageType is needed.
Please find below the related quote of the BPEL 2.0 spec:
The variable attribute, if it exists, identifies a variable local to the event handler that will contain the message received from the partner. [SA00087] The messageType attribute specifies the type of the variable by referencing a message type definition using its QName. The type of the variable (as specified by the messageType attribute) MUST be the same as the type of the input message defined by operation referenced by the operation attribute. Optionally the messageType attribute may be omitted and instead the element attribute substituted if the message to be received has a single part and that part is defined with an element type. That element type MUST be an exact match of the element type referenced by the element attribute. The variable and messageType/element attributes constitute the implicit declaration of a variable of that name and type within the associated scope associated of the event handler. If an element attribute is used then the binding of the incoming message to the variable declared in the event handler occurs as specified for the receive activity in section 10.4. Providing Web Service Operations – Receive and Reply .
Related
What's a subj parameter of a JetStream.PullSubscribe() method for?
I observe following behavior:
When a consumer is created without the FilterSubject configuration option, then no matter what I pass as subject to the js.PullSubscribe(), the subscription fetches all the consumer's messages.
When a consumer is created with a non-empty FilterSubject option, PullSubscribe returns with an error, if the subject differs from that filter.
Is this parameter of any use?
I've only found Microsoft's explanatory documentation for a single incident so far, where can i find a document includes all event with eventid?
The documentation for the EVENTLOGRECORD structure describes the EventID field as:
The event identifier. The value is specific to the event source for the event, and is used with source name to locate a description string in the message file for the event source. For more information, see Event Identifiers.
The referenced documentation for event identifiers goes on to explain:
Event identifiers uniquely identify a particular event. Each event source can define its own numbered events and the description strings to which they are mapped in its message file.
Since event sources are registered locally on systems, there is no global registry of all event sources. Consequently, with event identifiers being specific to event sources, there cannot be a global registry of all event identifiers. What you are asking for does not exist.
I am trying to understand what exactly is stored in an event using the SAPUI5 documentation here. Where can I find a list of parameters that come with an Event? For example, I just found out that DatePicker has a parameter called "valid", but how would I know that? Surely I wouldn't have to use getParameters() for every entity right? Also when you define a function to be called in XML, do they all send the same Event type?
In general the parameters depend on the intention of the event, e.g. a change event which indicates that the source object has changed its value contains other parameters than an event which informs you that a file upload has failed.
You'll find the available event parameters in API documentation. To stick with your example: Check the API documentation of the DatePicker control, select the change event from the available events and check the available parameter. You will find the parameter valid with a description. To see the difference between the events you may also check the ListBase implementation, which defines a bunch of events.
It is good style to use getParameter in your event handler to access the parameters values.
onDatePickerChanged : function(event) {
let validDate = event.getParameter("valid");
}
Is there a response to indicate that there is no value for that OID, or should it just return nothing?
It depends.
For example, the snmpget tool that is installed from the SNMP package on Debian both complains about a missing OID and doesn't, in a way.
Take for example, some basic SNMP OIDs:
root#debian:~# snmpwalk -v2c -cpublic localhost
...
iso.3.6.1.2.1.1.5.0 = STRING: "debian"
iso.3.6.1.2.1.1.6.0 = STRING: "Sitting on the Dock of the Bay"
Using snmpget will complain when you feed it a missing OID:
root#debian:~# snmpget -v2c -cpublic localhost iso.3.6.1.2.1.1.6.1
iso.3.6.1.2.1.1.6.1 = No Such Instance currently exists at this OID
However, it will return a zero code, signalling that it's "okay" that it doesn't exist:
root#debian:~# echo $?
0
If you're writing your own tool or script that reads from SNMP, it really comes down to how important it is for you to know that the OID is missing/invalid. I'd recommend checking out the net-snmp documentation/coding tutorials if you're looking for authoritative examples.
edit: And here are some RFCs if that's your sort of thing (links stolen from Lex Li's answer)
RFC 3416, 4.2.1 for SNMP v2c and above GET request processing
4.2.1. The GetRequest-PDU
A GetRequest-PDU is generated and transmitted at the request of an
application.
Upon receipt of a GetRequest-PDU, the receiving SNMP entity processes
each variable binding in the variable-binding list to produce a
Response-PDU. All fields of the Response-PDU have the same values as
the corresponding fields of the received request except as indicated
below. Each variable binding is processed as follows:
(1) If the variable binding's name exactly matches the name of a
variable accessible by this request, then the variable
binding's value field is set to the value of the named
variable.
(2) Otherwise, if the variable binding's name does not have an
OBJECT IDENTIFIER prefix which exactly matches the OBJECT
IDENTIFIER prefix of any (potential) variable accessible by
this request, then its value field is set to "noSuchObject".
(3) Otherwise, the variable binding's value field is set to
"noSuchInstance".
If the processing of any variable binding fails for a reason other
than listed above, then the Response-PDU is re-formatted with the
same values in its request-id and variable-bindings fields as the
received GetRequest-PDU, with the value of its error-status field set
to "genErr", and the value of its error-index field is set to the
index of the failed variable binding.
Otherwise, the value of the Response-PDU's error-status field is set
to "noError", and the value of its error-index field is zero.
The generated Response-PDU is then encapsulated into a message. If
the size of the resultant message is less than or equal to both a
local constraint and the maximum message size of the originator, it
is transmitted to the originator of the GetRequest-PDU.
Otherwise, an alternate Response-PDU is generated. This alternate
Response-PDU is formatted with the same value in its request-id field
as the received GetRequest-PDU, with the value of its error-status
field set to "tooBig", the value of its error-index field set to
zero, and an empty variable-bindings field. This alternate
Response-PDU is then encapsulated into a message. If the size of the
resultant message is less than or equal to both a local constraint
and the maximum message size of the originator, it is transmitted to
the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops
[RFC3418] counter is incremented and the resultant message is
discarded.
RFC 1157, 4.1.2 for SNMP v1 GET request processing
4.1.2. The GetRequest-PDU
The form of the GetRequest-PDU is:
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
The GetRequest-PDU is generated by a protocol entity only at the
request of its SNMP application entity.
Upon receipt of the GetRequest-PDU, the receiving protocol entity
responds according to any applicable rule in the list below:
(1) If, for any object named in the variable-bindings field,
the object's name does not exactly match the name of some
object available for get operations in the relevant MIB
view, then the receiving entity sends to the originator
of the received message the GetResponse-PDU of identical
form, except that the value of the error-status field is
noSuchName, and the value of the error-index field is the
index of said object name component in the received
message.
(2) If, for any object named in the variable-bindings field,
the object is an aggregate type (as defined in the SMI),
then the receiving entity sends to the originator of the
received message the GetResponse-PDU of identical form,
except that the value of the error-status field is
noSuchName, and the value of the error-index field is the
index of said object name component in the received
message.
(3) If the size of the GetResponse-PDU generated as described
below would exceed a local limitation, then the receiving
entity sends to the originator of the received message
the GetResponse-PDU of identical form, except that the
value of the error-status field is tooBig, and the value
of the error-index field is zero.
(4) If, for any object named in the variable-bindings field,
the value of the object cannot be retrieved for reasons
not covered by any of the foregoing rules, then the
receiving entity sends to the originator of the received
message the GetResponse-PDU of identical form, except
that the value of the error-status field is genErr and
the value of the error-index field is the index of said
object name component in the received message.
If none of the foregoing rules apply, then the receiving protocol
entity sends to the originator of the received message the
GetResponse-PDU such that, for each object named in the variable-
bindings field of the received message, the corresponding component
of the GetResponse-PDU represents the name and value of that
variable. The value of the error- status field of the GetResponse-
PDU is noError and the value of the error-index field is zero. The
value of the request-id field of the GetResponse-PDU is that of the
received message.
The behavior follows the standard RFC documents, like
RFC 3416, 4.2.1 for SNMP v2c and above GET request processing
RFC 1157, 4.1.2 for SNMP v1 GET request processing
I am in reference to the following method from BindingResult:
BindingResult.html#resolveMessageCodes(java.lang.String, java.lang.String)
I am trying to figure out the difference between an error code and a message code. Can someone please provide an example, especially one that would illustrate why there could be several message codes for a given error code?
Because web applications are internationalized, when you reject an object and want to have a message displayed for it, you don't use a hardcoded text because that will show the same no matter the language.
Instead, you specify an error code that later server as a key to retrieving the proper message from the bundles (and now the error code is a message code from the point of view of the method that must find the proper message text).
Your error code resolves to more message codes because Spring (based on the implementation) adds some additional ones for you. Here is a snippet from the Spring documentation:
[...] What error codes it registers is determined by the MessageCodesResolver that is used. By default, the DefaultMessageCodesResolver is used, which for example not only registers a message with the code you gave, but also messages that include the field name you passed to the reject method. So in case you reject a field using rejectValue("age", "too.darn.old"), apart from the too.darn.old code, Spring will also register too.darn.old.age and too.darn.old.age.int (so the first will include the field name and the second will include the type of the field); this is done as a convenience to aid developers in targeting error messages and suchlike. [...]
The last statement is the reason there are more message codes, to have control on the message that is displayed to the user, from a generic one (e.g. "Value required") to a more specific one given the context (e.g. "A value is required for field XXX").
The javadoc for DefaultMessageCodesResolver explains it further and gives an example:
For example, in case of code "typeMismatch", object name "user", field "age":
try "typeMismatch.user.age"
try "typeMismatch.age"
try "typeMismatch.int"
try "typeMismatch"
This resolution algorithm thus can be leveraged for example to show specific messages for binding errors like "required" and "typeMismatch":
at the object + field level ("age" field, but only on "user");
at the field level (all "age" fields, no matter which object name);
or at the general level (all fields, on any object).