Using WMQ7.0 with WMB 6.1
I have one flow where I am transforming a message and using MQRFH2.usr for holding some data.
But, I am facing the issue where the MQRFH2.usr is coming in the main message body.
I have deployed the same code in different environments, but I am getting this issue only in one environment.
So, it doesn't seems to be a code issue. It has something to do with configurations.
Kindly, suggest what could be the possible cause.
Check the queue's PROPCTL setting. If this is set to NONE then the behavior is as follows:
If the application does not create a message handle, all the message
properties are removed from the MQRFH2. Name/value pairs in the MQRFH2
headers are left in the message.
Be sure to read the doc page through a couple of times and maybe test with different settings to understand fully how PROPCTL modifies the message content your app receives.
The MQRFH2 headers, if present, always come in the payload part of the message (that's the way webpshere organizes it). You can receive one or more MQRFH2 headers (structures).
Perhaps you are expecting only one and are receiving two? This would explain your message data being left with gibberish.
I use the following code to handler these heards upon receiving a message
MQRFH2 header = null;
// Find and store message length
int msglen = replyMessage.getMessageLength();
MQHeaderList list = new MQHeaderList(replyMessage);
int indexOf = list.indexOf("MQRFH2");
if (indexOf >= 0) {
header = (MQRFH2) list.get(indexOf);
msglen = msglen - header.size();
}
String msgText = replyMessage.readStringOfCharLength(msglen);
Hope it helps.
Martins
Related
I'm creating client side streaming method which proto file definition should be looking similar to this:
service DataService {
rpc Send(stream SendRequest) returns (SendResponse) {}
}
message SendRequest {
string id = 1;
bytes data = 2;
}
message SendResponse {
}
The problem here is that ID is sent with each streaming message even it is needed only once. What's your recommendation and most optimal way for such a use cases?
One hacky approach would be to set ID only once within first message and after that left if blank. But this API is supposed to be used by third party and method definition like above doesn't explaining that well.
I don't think something like this is supported either:
service DataService {
rpc Send(InitialSendRequest, stream DataOnlyRequest) returns (SendResponse) {}
}
I'm currently considering SendRequest message to be something like this, but will have to check how optimal is this compared to the first case considering proto marshaling:
message SendRequest {
oneof request{
string id = 1;
bytes data = 2;
}
}
Your approach of using a oneof with the fields clearly documented saying id is expected only in the first message on the stream and that server implementations will terminate the stream if id is set on subsequent messages on the stream sounds good to me.
The following is a usage of the above described pattern in grpc-lb-v1. Even though the grpc team is moving away from grpc-lb-v1, the above mentioned pattern is a commonly used one.
I'm not very sure about its implications with respect to proto marshaling. That might be a question for the protobuf team.
Hope this helps.
I would like to send a stream of different protobuf messages through the wires and be able to differentiate them at arrival as they are coming.
Let's say I have a *.proto like that:
message Book {
//...
}
message BlueRay{
//...
}
And then and the sender side, I serialize let's say this sequence (pseudo code in C#):
Book1.WriteDelimitedTo(myStream);
BlueRay1.WriteDelimitedTo(myStream);
Book2.WriteDelimitedTo(myStream);
How can I do to know the order/types of messages I'm getting on the receiver side? (The contract is available on both sender and receiver side of course)
Depending of my sender's state I can not presume/tell what is going to be sent and in which order...
I understood that there is no built-in way to do that like stated in the documentation, but for instance for the size of the message there was a helper (C# API helper WriteDelimited method to embedd size).
How can I do to get/map the type of a received message?
My server will be written in a given language (C# actually), but my clients should be "implementable" in any protobuf supported target, so I don not want to set up something that would serialize C#/CLR specific stuff in between...
I'm maybe using protobuf in a weird way? I'm trying to set up a kind of protocol.
I think I finally found out how to do that (only in C# at the moment).
Basically, I'm writing the following to the stream:
the coming message descriptor's target name (in proto file, as both end share this definition), using the primitive for string serilization
the coming message size, using the primitive for size serialization
the serialized message into the stream
This results in a method like the following:
public static void WriteToStream(Stream outputStream, IMessage message)
{
MessageDescriptor stateMsgDescriptor = message.Descriptor;
using (CodedOutputStream codedOutStr = new CodedOutputStream(outputStream, true))
{
codedOutStr.WriteString(stateMsgDescriptor.FullName);
int size = message.CalculateSize();
codedOutStr.WriteLength(size);
message.WriteTo(codedOutStr);
codedOutStr.Flush();
}
}
As stated here,
The Protocol Buffer wire format is not self-delimiting, so protocol
buffer parsers cannot determine where a message ends on their own
I have inherited responsibility for a project from a previous developer which takes incoming emails and processes them into customer support tickets.
It mostly works fine but it is having problems with one particular email and I can't work out why.
In Outlook the email clearly has a body (some short text, an image and a signature). It is a new message and not a reply.
The exchange server version is 2013.
But when being processed by the code below UniqueBody is empty, while Body contains the correct text. This does not happen with any other emails I've come across on that server.
if (serverVersion >= ExchangeVersion.Exchange2010)
body = msg.UniqueBody.Text;
else
body = msg.Body.Text;
What would cause UniqueBody to be empty while Body is not?
Why would the previous developer prefer to use UniqueBody over Body, how do they differ?
Could be related to this?
Check if you request the properties correctly:
PropertySet ps = new PropertySet(ItemSchema.UniqueBody);
var email = EmailMessage.Bind(service, item.ItemId, ps);
If you do so, the UniqueBody-Property should not be empty.
As far as I know, UniqueBody should be set by the exchange-server to show you which part of the mail is relevant for your ticket:
https://msdn.microsoft.com/en-us/library/office/dd877075(v=exchg.150).aspx
If your customer answers later to the ticket-conversation, you only want the new text.
With a new mail/ticket: body == uniqueBody == "the text you want to use".
Slack has a Copy link feature, which copies a deep link to an individual chat message to the clipboard:
Here's an example of such a deep link (obfuscated):
https://myworkspace.slack.com/archives/CqwertGU/p1234567898000159
What I'd like to do is, get the details of that message from the Slack API given that link.
The first string after /archives/ is the channel's ID. I'm not quite clear about that second string though:
According to Slack's API documentation,
channels.history can also be used to pluck a single message from the
archive.
You'll need a message's ts value, uniquely identifying it within a
channel. You'll also need that channel's ID.
So, what I've found is that the p1234567898000159 value in the link above is almost the message's ts value, but not quite (the Slack API won't accept it): the leading p needs to be removed, also there has to be a . inserted after the 10th digit: 1234567898.000159
Putting all this together into an API request...
https://slack.com/api/channels.history?latest=1234567898.000159&channel=CqwertGU&count=1&pretty=1&token=mytoken123&inclusive=true
... I'm getting a response with all the message details, exactly what I need.
My question is: am I doing this right? Do I really need to craft the message's ts value from the URL parameter this way, or is there a better, more robust, officially supported way?
Im new in python, but i got same problem when i creating SlackBot (by SlackBolt), and i solved it like that:
link = 'https://***.slack.com/archives/C03UGEVQ6BX/p1668769293636169'
#Grab information from link
wrong_link_list = link.split('/')
wrong_ts = wrong_link_list[-1]
t_ts = wrong_ts.replace('p', '', 1)
dot = '.'
char_count = 10
#Put information in variables
channel = wrong_link_list[-2]
text = 'Hey dude!'
mess_ts = t_ts[:char_count] + dot + t_ts[char_count:]
app.client.chat_postMessage(channel=channel, text=text, thread_ts = mess_ts)
Hope this will help you!
I am building an SNMP Agent for a Windows application using the Microsoft WinSNMP API. Currently everything is working for single-item get and set-request, and also for get-next to allow walking the defined tree (albeit with some caveats that are not relevant to this question).
I am now looking at multi-item get and also get-bulk.
My current procedure is to iterate through the list of requested items (the varbindlist within the PDU), treating each one individually, effectively causing an internal get. The result is added to the VBL, set into the PDU, and then sent back to the SNMP Manager, taking into account invalid requests, etc.
My question is how should I handle "too much" data (data that cannot fit into a single transport layer message)? Or more accurately, is there a way to test whether data is "too big" without actually attempting to transmit? The only way I can see in the API is to try sending, check the error, and try again.
In the case of a get-request this isn't a problem - if you can't return all of the requested data, you fail: so attempt sending, and if the error report is SNMPAPI_TL_PDU_TOO_BIG, send a default "error" PDU.
However, it is allowable for a response to bulk-get to return partial results.
The only way I can see to handle this is a tedious (?) loop of removing an item and trying again. Something similar to the following (some detail removed for brevity):
// Create an empty varbindlist
vbl = SnmpCreateVbl(session, NULL, NULL);
// Add all items to the list
SnmpSetVb(vbl, &oid, &value); // for each OID/Value pair
// Create the PDU
pdu = SnmpCreatePdu(session, SNMP_PDU_RESPONSE, ..., vbl);
bool retry;
do {
retry = false;
smiINT failed = SnmpSendMsg(session, ..., pdu);
if (failed && SNMPAPI_TL_PDU_TOO_BIG == SnmpGetLastError()) {
// too much data, delete the last vb
SnmpDeleteVb(vbl, SnmpCountVbl(vbl));
SnmpSetPduData(pdu, ..., vbl);
retry = true;
};
} while(retry);
This doesn't seem like an optimal approach - so is there another way that I've missed?
As a side-note, I know about libraries such as net-snmp, but my question is specific to the Microsoft API.
The RFC does require you to do what you pasted,
https://www.rfc-editor.org/rfc/rfc3416
Read page 16.
There does not seem to be a function exposed by WinSNMP API that can do this for you, so you have to write your own logic to handle it.