I am using scala unit test(maven) with solace messaging. Use cases are publish message and consume message.
Question : Is there any standalone way(runs with maven life cycle from different environments like DEV, QA etc.. ) to mock solace connection object to test my publish and consume messages from the solace JMS queue?
Java Message Service(JMS) is an open standard.
Therefore, you can make use of any JMS mocking tools to perform this mock-up.
Related
We are trying to connect a process within our AS400 to deliver information to a database that is in SQL Server 2016. We have an Apache Kafka server running and ready. What is the best way to connect the i Series to SQL Server using Apache Kafka? in such a way that an RPGLE program can deliver a message subscribed to a specific topic in Kafka.
Should we install something additional? are there open source options?
What should we configure?
I suspect this should probably be closed...
But, I'll throw the following out here....
There's various ways for RPG to interact with REST services
open source HTTP API
IBM's own Integrated Web Services (IWS) client
Db2 built in functionality
various commercial libraries (GETURI for example)
Rather than interact directly from the producing RPGLE program, it's likely a better idea to have the RPG drop a message on a queue and have some background process send it out.
That background process could be all RPG, all Java, or RPG using Java classes.
JTOpen, aka JT400,is the opensource version of the IBM i Toolbox for Java.
If for instance you wanted an all Java process to read from the queue and send a message.
You can even throw Apache Camel into the mix since it supports both a JT400 and Kalfka connector. Here's an example repo of showing Camel running on the IBM i reading from a data queue and sending to Kalfka.
We need to make a full stack load testing. And the data journey is starting from mqtt client. Are there any good services to make a load testing for such case?
Depending on the number of virtual users you would like to simulate and your budget the options are in:
CloudMQTT service which is free for 5 connections and 10 Kbit/s bandwidth
Apache JMeter is a free and open source multi-protocol load testing tool. Out of the box JMeter does not support MQTT protocol however there are plugins like:
mqtt-jmeter
MQTT plugin
Check out Testing the MQTT Messaging Broker for IoT - A Guide
MQTT-Stresser
MQTT Toolbox
So feel free to choose one of the above (or other solution), the final choice mostly depends on your project infrastructure and possibility of i of test tool ntegration into your product delivery lifecycle
Here is my use case:
I have two endpoints: one with MQ and the second with TCP/IP
I have to replace a legacy server which accepts queries from remote TCP/IP clients. Once the socket is open with the client, data is exchanged in both sides. the server sends asynchronously MQ data through TCP/IP and receive data from clients asynchronously also. Each data message sent has to be acknowledged. The constraint here is that I have to use the same socket.
I created two routes
from("netty4:tcp://ipAddress:port?sync=true").to("wmq:queue:toQueue")
from("wmq:queue:fromQueue").to("netty4:tcp://ipAddress:port?sync=true")
I start the first queue to receive session open request from clients and then I start the second route to start sending data but I cannot use the same channel.
I tried to get the remote port of the first route and used it in the second route but I have a ConnectException because netty4 tries to open a new socket which is already open.
I found that netty4 can be used asynchronously using the AsyncProcessor but I didn't find any example dealing with my use case.
The only idea I found is that I have to create a standalone server which open the sockets with the clients and make it communicate with the two endpoints.
Is there any way to implement this situation using camel only?
any help on this subject is really appreciated.
Your code won't be able to run as it is for your use case. I also suspect you are trying to use Camel as IP server framework and not an integration in this case.
Lets review Apache Camel's concept of producers and consumers. In the integration world we talk about client and servers as consumers and producers. This might seem like a language difference until you realise a consumer(typically a client) can also be a producer(server).
Some helpful definitions:
1. Producer: A producer is an entity capable of creating and sending a message to an endpoint. A typical example would be code like .to("file:data/outbox") as this produces a file.
2. Consumer: A consumer is an entity that receives messages produced by a producer, it wraps these messages in an exchange and sends them to be processed. A typical example would be code like from(jms:topic:xmlOrders)
A rule of thumb is that typically consumers are the source of the messages being routed.
BIG NOTE:
These two definitions are not set in stone a producer can also be an endpoint using the from and a consumer can be an endpoint using the to.
So in your case let's break up the route:
from("netty4:tcp://ipAddress:port?sync=true").to("wmq:queue:toQueue")
In this route you are creating a Netty server that sends a message to a queue. Here your netty endpoint acts as a consumer(yes it is in the from clause) however this creates a Netty4 Server at the IP address and endpoint you specified. This then send a message to another consumer which is the MQ client which act as a consumer again. So two consumers? Where is the producer? The client connecting to the netty server will act as producer.
Let's look at the second piece of the route:
from("wmq:queue:fromQueue").to("netty4:tcp://ipAddress:port?sync=true")
Here you are creating a client/consumer for the MQ services and then creating a client/producer to the netty server. Essentially you are creating a NEW client here that connects to the SERVER you created in the first route.
So in short your route creates a Netty server that send a message to MQ then creates a MQ client that sends a message to a Netty client which connects to the server you have created. It wont work like this.
Go read about message exchange patterns for further reading, but I would suggest that if you are just using Netty and MQ then maybe Camel is a bit overkill as it is a integration platform and not a IP server platform.
Recently I need to develop JBOSS application which receives IBM MQ Message.
It seems like use wmq.jmsra.rar and Message Driven Bean is a most common solution.
But I'm a little bit uncertain who is responsible of this Resouce.
IBM? or Redhat?
I'd rather develop my own queue connector daemon which read message from IBM MQ and send to JBOSS MDB using JMS.
In this case, I need 2 phase commit, to commit simultaneously both IBM MQ side and JBOSS side. Can I use something like XATransaction on this process? Is there any example on Web if it's possible.
Sorry, I couldn't find any example so far.
Many thanks.
wmq.jmsa.rar is released by IBM. Its found as part of the product. Go with the latest release WMQ 7.5 if possible.
WMQ supports XA transaction. It can participate as a resource manager in a 2 phase transaction coordinated by an external transaction monitor/application server.
Sample programs for Java XA transaction are not found with the installation. (I know I have seen C and Cobol XA samples).
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/index.jsp?topic=%2Fcom.ibm.mq.dev.doc%2Fq023590_.htm
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/index.jsp?topic=%2Fcom.ibm.mq.dev.doc%2Fq031500_.htm
You will require a local qmgr (application should run on the same server as qmgr to connect in bindings mode) or extended transactional client to connect to a remote qmgr using XA transactions.
I need to implement a TCP server with a web interface included for management.
Basically, the tcp server will be listening to new connections and keeping current ones active while the web interface allow me to see information regarding these connections and to interact with them (e.g. send messages and seeing received ones)...
My concerns resides in the "TCP Server" integration with the web application.
For received messages I could simple use a shared DB, but I need to send messages to the peers connected into the TCP server.
My best bet is currently on JCA. Some research pointed me to a nice sample: http://code.google.com/p/jca-sockets.
The sample uses an Message Driven Bean to deal with messages received over port 9000, acting as an echo server.
I am new in the Java EE 6 world. I trying to figure out why things were done in one way or another in the sample (e.g. why MDB?).
JCA has a fairly complicated spec. So I am trying at first to adapt the sample above to keep the connections active to exchange data. My next step will be adapt it to accept a string over a servlet to forward it to a given peer.
Can someone help me out on this?
Well, first of all, using Java EE with TCP is not the best approach you may use. If you just need a simple TCP service with Web UI you'd better consider using Java SE with some web container attached (undertow works well).
In other hand, if you need your application to integrate into existing Java EE infrastructure your company has, JCA would be the best approach. While it's not designed for such kind of things, JCA is the only EE subsystem liberal enough for that kind of thread management you would need for TCP networking to work.
JCA-Socket you're referring above is not the best example of a JCA app. It uses plain Java's blocking sockets by blocking WorkManager thread, this is not very effective. Things got much better now and we have Java NIO and Netty for highly effective raw networking to work upon. I have a JCA connector for TCP interactions which may provide you a skeleton to build your own. Feel free to extend and contribute.
P.S. About MDB: message-driven bean is the only "legal" JCA approach of asynchronous incoming messages handling. Since TCP is asynchronous, you'll definitely need one in your application for all the things to start working. Outcoming data transfers happen through various ConnectionFactory interfaces you'll inject into your bean. The link above will provide you with a reference ConnectionFactory implementation as well as a simple tester app utilizing both ConnectionFactory and MDB messaging approaches.