There is a kafka connect connector for iothub. This is available from the confluent website (https://www.confluent.io/hub/microsoft/kafka-connect-iothub). However, the iothub connector in kafka connect is archived (see https://github.com/Azure/toketi-kafka-connect-iothub) and the last commit dates from 2018-03-19.
In the meantime the plugin does not work with the current version and needs to be updated.
Is there an alternative repo available. Did microsoft stop supporting this? Is there a plan?
The Kafka connector project for communicating with IoT devices is indeed retired.
If only one-way is desired, Event Hubs does have a Kafka compatibility layer and IoT Hub message routing can be used to take advantage of that scenario.
You can reach out via Azure Support Request if you are looking for other alternatives and we can share our roadmap under NDA. When you open the Azure Ticket, reference this SO thread.
Related
We have requirement, as per design, third party systems will push XML\CSV messages to IBM MQ queues, and we using Azure logic app need to consume those messages and send to Event hub.
My question is
As we dont have MQ available yet, and I am not able to give details in Azure and using Azure queues. Is there anyway we can mock like we are using MQ.
Logic app once receive messages XML can it store to Data lake instead of pushing through Eventhub(as Event hub storing message in AVRO format)
Any suggestions please.
Thanks
As suggested by Roger, you can install the developer version of IBM MQ to mock for Logic App testing.
Once the IBM MQ Queue is available, you can Send message from an on premise IBM MQ to Azure Service Bus queue and also able to Transform and Validate XML for workflows in Logic Apps.
You can refer to Connect to an IBM MQ server from a workflow in Azure Logic Apps, Transform XML for workflows in Azure Logic Apps and Validate XML for workflows in Azure Logic Apps
We are using a .NET Client using AMQPNetLite library to connect to ActiveMQ Artemis. I need to setup the pre-acknowledge mode and from the documentation, understood that this can be setup at the connector in broker.xml file. However, doing this didn't make any difference. It isn't very clear how to set this mode from the documentation.
The documentation you cited is for ActiveMQ Artemis clients using the native "core" protocol. It doesn't apply to the AMQPNetLite client. That client is developed in its own separate project which has its own documentation.
Also, for what it's worth, the documentation doesn't describe configuring pre-acknowledgement in broker.xml. It discusses configuring it on the client-side jndi.properties or programmatically via the JMS API. There is no way to configure pre-acknowledgement on the broker.
I recommend you take a look at "presettled" mode which is an AMQP semantic that should be essentially equivalent to pre-acknowdgement in ActiveMQ Artemis.
In terms of AMQP clients the idea of PRE-ACKNOWLEDGE mode would amount to creating the AMQP receiver link with the snd-settle-mode in the Attach frame to SETTLED so that the remote is informed that it should send your receiver deliveries that are already settled indicating the client wouldn't need to respond with a settled disposition itself as the remote has said it has already forgotten about the delivery.
As that relates to the AMQPNetLite you would be creating a ReceiverLink and giving it a custom defined Attach object with the settlement mode configuration you want which would like something like the below although you will need to test and tweak as needed.
Attach attach = new Attach();
attach.SndSettleMode = SndSettleMode.SETTLED;
attach.RcvSettleMode = RcvSettleMode.FIRST;
ReceiverLink receiver = new ReceiverLink(session, address, attach, onAttached);
Information about link establishment and Attach options can be found in the AMQP 1.0 specification.
I collect data from the LoRa node, and then gateway forward to lora server, at last, the data to the lora app server. but i cannot find the following interface.
(https://docs.loraserver.io/lora-app-server/integrate/data/)
enter image description here
You need to implement a MQTT client (or user a command-line one, like mosquitto_sub, as suggested in https://docs.loraserver.io/lora-app-server/integrate/data/) and then subscribe to the receiving topic for the specified node. The image you posted is not an interface but an example message a node will send through the topic. For the case given, appID is "123" and devEUI is "0202020202020202", so you need to subscribe to the following topic to get messages from the node:
application/123/node/0202020202020202/rx
As said, you may consume the messages through a MQTT client (there are plenty of clients for different languages), or from the command line.
Just updating from current versions.
Global integrations
Global integrations are configured through the lora-app-server.toml configuration file and are globally enabled. This means that for every application configured, the application will be published using this / these integration(s).
The following integrations are available:
MQTT
AWS Simple Notification Service
Azure Service Bus
Google Cloud Platform Pub/Sub
Application integrations
Additional to the globally enabled integrations, it is also possible to set up integrations per application.
The following integrations are available:
HTTP
InfluxDB
From: loraserver.io
I used IBM MQs on my local machine to connect to a remote IBM MQ Queue Manager on a client machine for sending and receiving messages.
Due to some issues I need to uninstall IBM MQs on my end.
Can I connect to the client remote queue manager using Apache ActiveMQ? (With SSL)
If possible please guide me how to proceed with it.
If not please suggest any alternative solutions to connect.
No. Connect to it using the WebSphere MQ Client. It is freely downloadable as SupportPac MQC75 and includes support for several languages, including C and Java. Rather than just grabbing the jar files, please install the entire client distribution. IBM includes a number of diagnostic utilities, tracing and so forth in that distribution. These make debugging much easier and IBM requires them to be installed if you open a support ticket. Since the client is free, requiring the diagnostic tools to be installed seems reasonable.
The documentation for the client is here.
Active MQ uses a different wire protocol and its client won't work with WebSphere MQ.
I'm currently using Socket.IO with redis store.
And I'm using Room feature with it.
So I'm totally okay with Room join (subscribe)
and Leave (unsubscribe) with Socket.IO.
I just see this page
http://www.rabbitmq.com/blog/2010/11/12/rabbitmq-nodejs-rabbitjs/
And I have found that some people are using Socket.IO with rabbitMQ.
Why using Socket.IO alone is not good enough?
Is there any good reason to use Socket.IO with rabbitMQ?
SocketIO is a browser --> server transport mechanism whereas RabbitMQ is a server --> server message bus.
The two can be implemented together to create a very responsive system in scenarios where a user journey consists of a message starting life on a browser and ending up in, say, some persistence layer (such as a database).
A message would be transported to the web server via socketIO and then, instead of the web server being responsible for persisting the message, it would drop it on a Rabbit queue and leave some other process responsible for persisting it. This way, the web server is free to return to its web serving responsibilities and, crucially, lessening its load.
Take a look at SockJS http://sockjs.org .
It's made by the RabbitMQ team
It's simpler than Socket.io
There's an erlang server for SockJS
Apart from that, there is an experimental project within RabbitMQ team that intends to provide a SockJS plugin for RabbitMQ.
I just used rabbitMQ with socket.io for a totally different reason than in the accepted answer. It wasn't that relevant in 2012, that's why I'm updating here.
I'm using a docker swarm deployment of a chat application with scalability and high availability. I have three replicas of the chat application (which uses socket.io) running in the cluster. The swarm cluster automatically load-balances the incoming requests and at any given time a client might get connected to any of the three replicas of the application.
With this scenario, it gets really necessary to sync the WebSocket responses in the replicas of the application because two clients connected to two different instances of the application wouldn't get each other's messages because they've been connected to different WebSockets.
This is where rabbitMQ intervenes. It syncs all the instances of the application and whenever a message is pushed from a WebSocket on a replica, it gets pushed by all replicas.
Complete details of the project have been given here. This is a potential use case of socket.io and rabbitMQ use in conjunction. This goes for any application using socket.io in a distributed environment with high availability and scalability.