As far as I understand, the SEME (sender's message reference) attribute of a SWIFT MT message has to be unique per sender (it is the sender's responsibility to ensure uniqueness). So, let's say there are two sending entities A and B and I am the receiver. Then it would be a valid scenario to have both of them send out a SWIFT MT message with the same SEME, right? How could I differentiate messages coming from sender A and B? What is common practice in such a case?
In the documentation (MT 558 in that case) it says:
Reference assigned by the triparty agent to unambiguously identify the
message.
The MIR in the {2: Application Header Block} seems to be the one according to me.
MIR: message input reference, unique identifiers containing the date, logical terminal (including branch code), session and sequence numbers.
Info source: https://www.prowidesoftware.com/about-SWIFT.jsp
Related
I have 2 APNs, they share the same provider, same device token. First one is delivered, second one not.
payload={"aps":{"badge":0,"alert":{"action-loc-key":"View","body":"Some guy: Hey man"},"sound":"NewMessage.caf"}} <- this one is delivered
payload={"aps":{"badge":0,"alert":{"action-loc-key":"","body":""}}} <- this one not delivered
I could not find any info about empty body in Apple docs.
So, why it's not delivered?
The payload must include an alert dictionary with title, subtitle, or body information.
Empty values are treated as missing.
I used veins 4a2 and OMNET++ (4.6). I like to know the content of messages exchanged between vehicles in the veins example.
I have consulted waveshortmessage.msg, WaveShortMessage_m.cc and WaveShortMessage_m.h but I have not found messages content.
In waveshortmessage.msg, what means this line "string wsmData = "Some Data"" please?
And in TraCIDemp11p.cc, what means "blockedRoadId" declared in sendMessage function?
The demo application that comes with Veins 4.4 (and 4a2 as well) and that is used for the Veins tutorial reacts to messages that contain the name of a road to avoid because a car has stopped there for longer than 10s (and vice versa: the demo application sends a message when a car is stopped for longer than 10s).
The demo application is defined in TraCIDemo11p. It uses a demo message type, WaveShortMessage, as the container to inform other cars about a blocked road. For this, it stores the name of the blocked road (variable blockedRoadId) in the wsmData field of the message.
I'm using the github.com/hypebeast/go-osc/osc package to send OSC messages to an OSC server. For this I'm using OSCulator so that I can route the data as MIDI to Abelton Live.
The problem I'm having is I can not find any information on message formatting for things like note on, note off, duration etc. I found a guide on the OSCulator website that's a little helpful, but it doesn't go into much detail on messaging: http://s3.amazonaws.com/osculator/doc/OSCulator+2.12+Manual.pdf
For example, the following function works just fine, but I have no idea what the message is really doing:
func note(pitch float32 , velocity float32) {
// TODO: Pass client into function. Find out it's type.
client := osc.NewClient("localhost", 8765)
noteMsg := osc.NewMessage("/4/toggle2")
client.Send(noteMsg)
msg := osc.NewMessage("/4/xy")
msg.Append(pitch)
msg.Append(velocity)
client.Send(msg)
}
I mean, what purpose does the 4 play in this, and what is xy? Also, what other messages are available apart from toggle2? I thought there would be some sort of documentation online that has all the different types of messages available for MIDI type applications.
Your question seems to be more related to OSC itself.
OSC works like this:
You send a message to a server. A message is composed by an adress and some values.
In this case, /4/xy is the address. The 4 and the slashes you define what will be. When you receive it on the other side you will know what you want to receive, which means the address you're sending. So you will configure the server or the receiver to do something when it receives a message from a specific adress.
In the same way, you are appending values to the message. The quantity of values you already know, so you just have to do what you want with them when you receive.
Basically, if you decide to have a keyboard sending notes, you would use something like /keyboard/note as adress and send one value at a time, so you would read this value and do something with it.
£ and ê in a XML message is parsed successfully in broker but when one of the Queue manager tries to put the output message in another Queue manager, It throws 'Unconvertable character' exception and message goes to dead letter queue.
Channel conversion is turned on and CCSID in both the queue managers is set to '819'.
What shall be done to avoid this?
Need Help on this..!!
Update Nov 15
There is more thing that we can check If we are facing this issue.
I was posting the message from RFHUTIL, and in MQMD tab, value in code page field was set to 457. So this was one of the reasons in faillure.
I posted the same message again with code page value as 819 and then the same XML message worked fine.
So, if you are facing the same issue, you might wanna check the RFHUTIL settings as well.
The mentioned characters doesn't come under CCSID 819.
And as the channel conversion is ON, queue manager will try your message to convert the message into it's own CCSID(819), which will fail to do so as the characters are not supported.
Solutions could be:
1) Turn off channel conversion.
2) Change the CCSID of your queue managers to 1208.
Huge topic data conversion, and it depends on the language you use. A general summary is make sure the codedcharsetid for the message in the MD matches the characters codepoints in the message. Then, make sure when you get the message you get/convert and make sure you are either running in a locale which can display those characters OR put a ccsid in the MD prior to the get. If you use .net or Java then there are implications although the same remains true.
Here's what I'm attempting to do: Let's assume that you are in mail and create a New blank mail message, then enter some data into it, such as body copy, etc. (in my case, the message was created through scripting bridge using the "Mail Contents of this Page" from safari... the main purpose of this process for my application.)
From my application, I want to select that message and assign it to:
MailOutgoingMessage *myMessage;
so that I can programmatically add recipients. I've tried several ways of doing this which seemed logical, but so far I haven't found the right combination, and the header file doesn't seem to be very clear to me (I'm new to scripting bridge.)
My initial thought was to try this:
mailMessage = [[mail outgoingMessages] lastObject];
Which should grab the last outgoing message created. It seems to work in that I am able to add recipients to mailMessage (though there have been a few times that I received unexpected results when multiple outgoing messages exist, such as adding the recipients to the wrong message) but attempting to log the subject line of the message:
NSLog(#"Subject = %#",[mailMessage subject]);
always returns NULL even though there is a subject clearly viewable in the subject field of the message. NULL is returned for any other parameter as well.
I'm gathering it must be a problem with my assignment to mailMessage above, because the only time I receive a NULL for message properties (or receive unexpected results) is if I try to point mailMessage to an existing outgoing message. If I create the mail message with scripting bridge, then I can retrieve all of the properties correctly.
Does anyone understand the hierarchy of the Mail scripting enough to tell me why I am getting NULLs for the parameters using the above assignment for mailMessage? What would the simplest way be go grab my message so that I can add recipients and later call the:
[myMessage send];
method? Any insight would be helpful. I've spent a week going through the mail.h header file and am quite literally at a loss as to what else to try at this point.
There's no way to (send, get or set the properties of the outgoing message) that the user or Safari has created.
It's a bug (it stopped working since Mac OS X 10.4), or some privacy/security considerations.