OpenNMS events varbinds decode always showing the raw value between (parentheses) - variables

Is there a way to hide the raw value from a varbind that was decoded?
What I'm getting is:
deviceNotification trap received deviceRuleCode=browserOffline(7) notifObjType=trigger(1) notifObjSeverity=critical(6)
What i want is:
deviceNotification trap received deviceRuleCode=browserOffline notifObjType=trigger notifObjSeverity=critical
Obviously I'm passing the decoded varbinds parm[#] to the log message and/or description.
Any clue? Is it even supported?

After check the code, I've concluded that this is not supported.
The proof is here:
https://github.com/OpenNMS/opennms/blob/develop/features/events/daemon/src/main/java/org/opennms/netmgt/eventd/processor/expandable/ExpandableParameter.java#L75-L77
The token having the decoded value is always appended with the original value:
(...)
ret.append(decode.get(token).get(value));
ret.append("(");
ret.append(value);
ret.append(")");
(...)
.. and this happens for all the expanded values.

Related

ERROR: Limit set by ERRORS= option reached. Further errors for this INPUT function will not be printed

While using the code able I'm getting an error message as below and also I'm getting the output table.
input(put(serv_to_DT_KEY,8.),yymmdd8.)
between datepart(D.throughdate)
and datepart(intnx('day',d.throughdate,31))
Error: INPUT function reported 'ERROR: Invalid date value' while processing WHERE clause.
ERROR: Limit set by ERRORS= option reached. Further errors for this INPUT function will not be printed.
Could you please help
It's not a true error, exactly; it's a data error, which SAS will let by. What it's saying is the value in serv_to_DT_KEY is not a valid yymmdd8 for some records. (The rest of the message, about "limit set by ...", is just SAS saying it's only going to tell you about 20 or so individual data errors instead of showing you every single one, so your log isn't hopeless.)
To fix this you have several options:
If there is a data issue [ie, all rows should have a valid date], then fix that.
If it's okay that some rows don't have a valid date (for example, they might have a missing), you can use the ?? modifier in the informat in input to tell it to ignore these.
Like this:
input(put(serv_to_DT_KEY,8.),?yymmdd8.)
between datepart(D.throughdate)
and datepart(intnx('day',d.throughdate,31))

In POP3, what is the expected first response line to a RETR command?

I'm learning about POP3 by reading RFC 1939.
The description of the RETR command says the following:
Possible Responses:
+OK message follows
-ERR no such message
Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .
What does "120 octets" refer to? Is this optional information about the message that may or may not be included, and if so, is "message follows" not required (as specified under "Possible Responses")?
What does "120 octets" refer to? Is this optional information about the message that may or may not be included
Correct, the "120 octets" is optional informational text but is not required text nor can the number of octets be used as definitive for calculating the end of the message data.
and if so, is "message follows" not required (as specified under "Possible Responses")?
That's why it was stated to be a "possible response" ;-)
Basically, all you can really use from that first line is the first token which will be "+OK" or "-ERR". Everything after that is informational text that may be a helpful when debugging, but not guaranteed to be useful for your code to try and interpret.
I would argue that if it is of the form "# octets", you might be able to use it to show progress as you read data, but that's about the best you can do.
Even so, I would probably recommend using the octet value from the LIST command instead.

UI5 Odata batch update - Connect return messages to single operation

I perform a batch update on an OData v2 model, that contains several operations.
The update is performed in a single changeset, so that a single failed operation fails the whole update.
If one operation fails (due to business logic) and a message returns. Is there a way to know which operation triggered the message? The response I get contains the message text and nothing else that seems useful.
The error function is triggered for every failed operation, and contains the same message every time.
Maybe there is a specific way the message should be issued on the SAP backend?
The ABAP method /iwbep/if_message_container->ADD_MESSAGE has a parameter IV_KEY_TAB, but it does not seem to affect anything.
Edit:
Clarification following conversation.
My service does not return a list of messages, it performs updates. If one of the update operations fails with a message, I want to connect the message to the specific update that failed, preferably without modifying the message text.
An example of the error response I'm getting:
{
"error":{
"code":"SY/530",
"message":{
"lang":"en",
"value":"<My message text>"
},
"innererror":{
"application":{
"component_id":"",
"service_namespace":"/SAP/",
"service_id":"<My service>",
"service_version":"0001"
},
"transactionid":"",
"timestamp":"20181231084555.1576790",
"Error_Resolution":{
// Sap standard message here
},
"errordetails":[
{
"code":"<My message class>",
"message":"<My message text>",
"propertyref":"",
"severity":"error",
"target":""
},
{
"code":"/IWBEP/CX_MGW_BUSI_EXCEPTION",
"message":"An exception was raised.",
"propertyref":"",
"severity":"error",
"target":""
}
]
}
}
}
If you want to keep the same exact message for all operations the simplest way to be able to determine the message origin would be to add a specific 'tag' to it in the backend.
For example, you can fill the PARAMETER field of the message structure with a specific value for each operation. This way you can easily determine the origin in gateway or frontend.
If I understand your question correctly, you could try the following.
override the following DPC methods:
changeset_begin: set cv_defer_mode to abap_true
changeset_end: just redefine it, with nothing inside
changeset_process:
here you get a list of your requests in a table, which has the operation number (thats what you seek), and the key value structure (iwbep.blablabla) for the call.
loop over the table, and call the method for each of the entries.
put the result of each of the operations in the CT_CHANGESET_RESPONSE.
in case of one operation failing, you can raise the busi_exception in there and there you can access the actual operation number.
for further information about batch processing you can check out this link:
https://blogs.sap.com/2018/05/06/batch-request-in-sap-gateway/
is that what you meant?

What is the correct SMPP error code to indicate corrupt/invalid UDH field values?

I'm trying to handle UDH data for multipart messages and I want to use an appropriate error code when there's a problem with the multipart fields. There are several error codes for bad TLV's, but I don't see anything except generic failure messages that I could use for UDH. Is that the best I can do here, or is there a more direct message I could use?
Your observation is correct - there is not a single error defined for UDH.
If you want, you can use error codes from reserved section and assign specific meaning to one/some of them. I think the "Reserved for SMSC vendor specific errors" (0x400-0x4FF) can be a good candidate.
Actually it looks to me like ESME_RX_R_APPN = 0x66 "ESME receiver reject message error." is the best error code to throw here.
It should correspond to a permanent error for this message only and let further messages be processed.

Quickfixn - Tag Appears More Than Once Rejection

I'm having an issue with Quickfixn and I'm hoping someone with more experience working with it can shed some light on an issue I'm facing. For some reason, messages are getting rejected by the QuickFix engine because of repeating tags... I expect to have repeating tags and so I set the UseDataDictionary flag = Y in my config file but messages are still getting rejected. Has anyone experienced a similar issue ?
The message I'm receiving looks like :
8=FIXT.1.1 9=421 35=AE 34=8 1128=8 49=XXX 56=YYY 52=20130501-15:45:53 552=1 54=2 37=130501-5 11=NOREF 826=0 78=1 79=default 80=1000000.00 5967=12167800.00 453=4 448=ITXT 452=3 447=D 448=TEST 452=1 447=D 448=LMEB 452=16 447=D 448=FRTB 452=11 447=D 571=6718487 150=F 32=1000000.00 15=USD 1056=12167800.00 31=12.1678 194=12.1678 195=0 64=20130503 63=0 60=20130501-00:00:00 75=20130501 1057=Y 460=4 167=FOR 65=SP 55=USD/MXN 10=203
8=FIXT.1.1 9=124 35=3 34=8 49=XXX 52=20130501-15:45:54.209 56=YYY 45=8 58=Tag appears more than once 371=448 372=AE 373=13 10=210
my config file looks like this:
[DEFAULT]
ConnectionType=initiator
HeartBtInt=30
ReconnectInterval=10
SocketReuseAddress=Y
FileStorePath=D:\Store
FileLogPath=D:\Log
[SESSION]
BeginString=FIXT.1.1
SenderCompID=XXX
TargetCompID=YYY
DefaultApplVerId = FIX.5.0SP1
UseDataDictionary=Y
AppDataDictionary=D:\Interface\FIX50SP1.xml
StartDay=sunday
StartTime=20:55:00
EndTime=06:05:00
EndDay=saturday
SocketConnectHost=1.1.1.1
SocketConnectPort=8443
Any help would be greatly appreciated! Thank you.
Often this happens because there is a field in a repeating group that is not specified in the DataDictionary. The parser sees the field and assumes the repeating group has ended. It continues parsing fields as if they are not part of a group. If it sees a duplicate field in this context, the parser will report an error.
You may clone and modify FIX Data Dictionary (D:\Interface\FIX50SP1.xml) to fit your needs, if you need to process "invalid" messages. Or you may disable message validation.