With MQTTLibrary for Robot Framework, is it possible to determine the exact topic of a received message? - robotframework

I'm a new Robot Framework user, and I've added the MQTTLibrary.
I can set up a subscription as per the documentation, and successfully receive messages. It's also possible to subscribe to wildcards, e.g.
${message}= Subscribe topic=test/mqtt_test/+ qos=1 timeout=2
The above will successfully pick up messages published to test/mqtt_test/apples, test/mqtt_test/oranges, test/mqtt_test/pears etc.
However, ${message} appears to only contain the content of the message payload, and I've been unable to work out if it's possible to determine the exact topic of the received message.
Can this be done with MQTTLibrary?
=============
Additional details (to provide an answer to ILostMySpoons's comment):
Sure - it's basically just the message content. So if I use...
mosquitto_pub -h 127.0.0.1 -t test/mqtt_test/apples -m "Hello to you"
...and my robot framework script does...
Log to console ${message}
...I see...
['Hello to you']
The debug output from the mosquitto broker (mosquitto -v) doesn't show message payloads but it does show the full topic path of test/mqtt_test/apples.

I've taken a deeper look into the MQTTLibrary and have come up with a solution. I'm both a Robot Framework and Python noob, so this may not be the best/most appropriate implementation, but it seems to work.
On my installation, the MQTTLibrary source is contained in C:\Python27\Lib\site-packages\MQTTLibrary. Everything of interest is in the MQTTKeywords.py file.
In the _on_message_list() function, change...
self._messages.append(message.payload)
...to...
self._messages.append([message.topic, message.payload])
Use the Subscribe keyword in your Robot Framework script as before, but you'll now have a list of lists; specifically each entry in the list will be a list of [topic, payload]. E.g.
${messages}= Subscribe topic=test/mqtt_test/+ qos=1 timeout=20 limit=0
${third_message}= Get From List ${messages} 2
${topic}= Get From List ${third_message} 0
${payload}= Get From List ${third_message} 1
Log to console \nTopic:\n${topic}
Log to console \nPayload:\n${payload}
The above example assumes that at least 3 messages were received during the 20 second timeout window.
Note that this change would break existing scripts, so a more complete solution would perhaps need to add new keywords (e.g. Subscribe And Get Topics), with additional work to ensure Subscribe still returns just the payloads.

Related

Symfony - background task from form setup

Would you know how to run a background task on Symfony 4, based on the setup of a form ? This would avoid that the user has to remain on the form until the task is finished.
The idea would be that when the form is validated, it starts an independant background task. Then the user can continue its navigation and come back once the task is finished to get the results.
Thanks for your help,
You need to use pattern Message Bus. Symfony has own implementation of this pattern since version 4.1 introducing Messenger Component.
You can see documentation here: https://symfony.com/doc/current/components/messenger.html
To get it work you need some external program that will implement AMQP protocol. Most popular in PHP world IMHO RabbitMQ.
A very simple solution for this could be the following procedure:
Form is valid.
A temporary file is created.
Cronjob gets executed every five minutes and starts a symfony command.
The command checks if the file exists and if it's empty.
If so, the command works of the background task. But before this, the command write it's process id in the file to prevent from beeing excuted a second time.
Remove the file when the command has finished.
As long as the file exists you can show a hint for the user that the task is running.

Quectel BG96 MQTT publish error

I'm try to publish my data to ThingsBoard server i use this types of AT commands
AT+QIACT=1
OK
AT+QMTOPEN=1,"demo.thingsboard.io",1883
OK
AT+QMTCONN=1,"demo.thingsboard.io","MY_ACCESS_TOKEN",""
OK
AT+QMTPUB=1,0,0,0,"v1/devices/me/telemetry"
>{"temperature":35.00,"humidity":80.00} // MY_POST_DATA This line hanging my module
All AT commands response is ok But i finally enter MY_POST_DATA the module doesn't provide no response hanging the previous command.. and i check my ThinksBoard data never post telemetry..
Please help any one how can i fix this problem and publish MQTT server.
Step 1: Get hold of the official AT command documentation for the modem (Quectel BG96 I assume?). It should document how the AT+QMTPUB command behaves and what it expects. Everything else is just guessing. The manufacturer should provide this, and if not you should demand to get one.
...
Step 873, when you have exhausted absolutely all possible ways of getting hold of the official AT command documentation for the modem: You can try my guess that the command behaves similar to other commands that read arbitrary length user data, most notably AT+CMGS which sends SMS messages, which expect a Ctrl-Z (ascii value 26) as an end of data indicator.
+QMTPUB: 1,0,0 simply mean that BG96 has successfully published and your broker (thingsboard) have also acknowledged publication of message.
If you can't see data on broker, then please check if the topic you are publishing is correct or not.
It may happen you are publishing to another topic (or to a different PATH).
Ask 'thingsboard' for help regarding proper topic.

BizTalk TPE continuations and uncompleted activities

Within my BizTalk 2010 solution I have the following orchestration that’s is started by the receipt of a courier update message. It them makes a couple of call to AX's WCF AIF via two solicit-response ports, a Find request and an Update request.
For this application we are meeting audit requirements through use of the tracking database to store the message body. We are able to link to this from references provided in BAM when we use the TPE. The result for the customer is nice, they get a web portal from which they can view BAM data of message timings etc. but they can also click a link to pull up a copy of the message payloads from the tracking db. Although this works well and makes use of out-of-box functionality for payload storage it has led to relatively complex jobs for the archiving of the tracking db (but that's another story!).
My problem relates to continuation. I have created the following Tracking Profile:
I have associated the first of the orchestration's two solicit response ports with the continuation RcvToOdx based on the interchange Id and this works, I get the following single record written to the Completed activity table:
So, in this case we can assume that an entry was first written on receipt in the inbound message, with the TimeReceivedIntoBts column populated by the physical file receive port. The FindRequestToAx column was then populated by the physical WCF send port. Because this was bound to the RcvToOdx continuation Id and used the same interchange Id and the previously mentioned file receive message, the update was made to the same activity. Notification of the resulting response was also updated to the same activity record - into the FindResponseFromAx column.
My problem is that I would also like BAM to record a timestamp for the subsequent UpdateRequestToAx. Because this request will have the same interchange Id as the previous messages I would expect to be able to solve this problem by simply binding the AxUpdate send port (both send and receive parts of it) to the same continuation id, as seen in the following screen grab:
I also map the UpdateRequestToAx milestone to the physical Ax_TrackAndTraceUpdate_SendPort (Send) and the OrchestrationCompleted milestone to Ax_TrackAndTraceUpdate_SendPort (Receive)
Unfortunately, when I try this I get the following result:
Two problems can be seen from the above db screen grab:
1. Date for the update send port was inserted into a new activity record
2. The record was never completed
I was surprised by this because I'd thought since they update port was enlisted to use the same continuation, and the single InterchangeId was being used by all ports for the continuation Id then all the data milestones would be applied to a single activity.
In looking for a solution to this problem I came across the following post on Stack Overflow suggesting that the continuation must be closed from the BAM API: BAM Continuation issue with TPE. So, I tried this by calling the following method from an expression shape in my orchestration:
public static void EndBAMContinuation(string continuationId)
{
OrchestrationEventStream.EndActivity(CARRIER_ORDER_ACTIVITY_NAME, continuationId);
}
I can be sure the method was called ok because I wrapped the call with a log entry from the CAT framework which I could see in debug view:
I checked the RcvToOdx{867… continuation Id against the non-closed activity and confirmed they matched:
This would suggest that perhaps the request to end the continuation is being processed before the milestone of the received message from the UpdateAx call?
When I query the Relationsips tables I get the following results:
Could anyone please advise why the UpdateToAx activity is not being completed?
I realise that I may be able to solve the problem using only the BAM API but I really want to exhaust any possibility of the TPE being fit for purpose first since the TPE is widely used in other BizTalk solutions of the organisation.
To solve this problem I created a 2nd continuation in the TPE.
"RcvToOdx" continuation for the Find and "OdxToUpdate" continuation for the update - source is InterchangeId on the initial receive port - UPS_TrackAndTrace (same as for other "RcvToOdx" continuation), dest Id is the InterchangeId mapped to update send port.

What could cause a message (from a polling receive location) to be ignored by subscribing orchestration?

I'll try provide as much information as possible:
No error message.
The instance stays in the "ready service instances".
The receive location has the same parameters (except URI, the three polling queries, user account/pw and receive pipeline) as another receive location that points to another database/table which works.
The pipeline is waiting for the correct schema.
The port surface and receive location are both waiting for the correct schema.
In my test example, there are only 10 lines being returned.
The message, which contains those 10 lines, validates against the schema.
I tried to let the instance alone to no avail - 30+ minutes - and no change in its condition.
I had also tried suspending and then resuming it which then places the instance in the "dehydrated orchestrations" list. Again, with no error message.
I'm able to get the message by looking at the body of the message that's in the "ready to run" service. (This is the message that validates versus the schema I use in Visual Studio.)
How might something like this arise?
Stupid question, but I have to ask... Is the corresponding host instance running?

Biztalk Message Promotions

I'm relatively new to Biztalk and I'm having a bit of hassle with this:
I have built a simple orchestration, hooked it up correctly to a receive port, I'm using the correct schema and map and the orchestration seems to be subscribing ok.
However, when the file I want to process gets picked up at the port I'm getting the 'could not be routed because no subscribers were found' error.
I ran a HAT query and can see the orch has an active subsription to the correct thing, is there anything else I can check on this?
Is your port hooked directly to the orchestration or is the orchestration picking the message up from the message box? Has the orchestration receive been set to Activate?
What does your subscription filter look like for the orchestration?
As a futher test:
a) create a sendport (FILE)
b) add a filter to it; BTS.ReceivePortName =
c) grab the resulting file - it should be the XML thats produced by your Custom PL
d) Use this file with a receive location using an XML Receive PL and see how your orchestration reacts to
This will at least rule out a Pipeline issue...
HTH
Check your pipeline is XMLReceive. This will promote the MessageType property and hopefully your orchestration will subscribe successfully.
Find the failed message in HAT and look at the body of the message. Copy it out and then run validate it against the schema of the message you are expecting. If it doesn't validate then you have set your flat file disassembler up incorrectly.

Resources