Non responsive UDP message on FME cloud

Question

FME Server has the ability to receive UDP messages and process them with a FME workspace.

1. Choose a port that you would like FME Server to receive UDP messages on (eg 55214).

Make sure that this port can be accessed from the client that is sending UDP messages. You may need to create a firewall rule to allow this access.

2. Create a workspace that reads the UDP message and performs some action with the content.

Start by adding a Text File reader set to read any file. This gives the UDP message an entry point into the workspace. Add transformers to work with the UDP messages. The most simple example is to add an AttributeWriter transformer that will write the UDP message out to disk.

3. Publish the workspace to FME Server and at the register with services screen:

Check on the Subscription Service and click edit, Click the ellipsis (...) button next to Assigned Topics, Click New Topic... Enter a topic name and then click OK, Check on the new topic and click OK, Click OK and then Publish.

4. Create the UDP Publication

Open the Web Interface > Notifications > Publications > New Enter a name for the publication. Select UDP for the protocol. Enter the port you chose earlier. Select the Topic you created earlier. Click OK.

5. Send a UDP message to FME Server.

You can configure your UDP client to send to FME Server or use a test tool. Search for 'UDP Test Tool' to find a free one.

So, after all this when i try to set up a sensor to send UDP messages to FME Cloud via a GSM modem and it works great as a trigger, but the message that arrives is un non understandable.

I believe everything is sent as bytes through the serial port so I have no idea whether its possible to format it before sending or the problem is how FME Cloud is receiving the data.

Answer 1

It looks like the messages from the UDP trigger are coming through in their raw binary form .

In my test, I sent "Hello world!" to FME Server via UDP and it came through as "SGVsbG8sIHdvcmxkIQ==" .

I was able to 'unscramble' the message within a Workspace using the BinaryDecoder transformer.

In my case, I set the Encoding Type to Base64 and the Character Encoding for Output Data to System Default to get the proper string output.

I'll check with our team here to confirm if this is expected behaviour.

I also would have expected the messages to automatically be decoded when FME Server/Cloud receives them.