I'm working on a BPEL process that includes an email service, and is generally kicked off by an AQ Adapter. The composite pulls email addresses from a DVM lookup and from the content returned by a service invoke.
My code that assigns the email addresses looks something like this:
concat(bpws:getVariableData('EmailVariable'),',',bpws:getVariableData('ServiceOutputVariable, 'ServiceVariablePart','Email')
Where "EmailVariable," is two comma separated addresses and "Email," is a single email address
When BPEL is called via the AQ Adapter, the "to" line of the email comes back as EmailA,EmailBEmailC.
When I wired it to a file adapter for debugging, though, the "to" line reads "EmailA,EmailB,EmailC" (The desired result, obviously).
The only thing that changed from the AQ adapter version to the File Adapter version is the source of the kickoff value.
What could be causing this inconsistent behavior?
Obvious first question is have you posted this in the Oracle SOA forum or searched oracle.support to see if it is a bug?
Anyway, put a mediator between the AQ interface and BPEL and have the mediator resolve the issue, through data transformation, which is its purpose in the first place and best practice design pattern: isolate your service implementation from the service interface.
Related
You have a command/operation which means you both need to save something in database end send an event/message to another system. For example you have an OrderService and when a new order is created you want to publish an "OrderCreated"-event for another system/systems to react on (either direct message or using a message broker) and do something.
The easiest (and naive) implementation is to save in db and if successful then send message. But of course this is not bullet proof because the other service/message broker is down or your service crash before sending message.
One (and common?) solution is to implement "outbox pattern", i.e. instead of publish messages directly you save the message to an outbox table in your local database as part of your database transaction (in this example save to outbox table as well as order table) and have a different process (polling db or using change data capture) reading the outbox table and publish messages.
What is your solution to this dilemma, i.e. "update database and send message or do neither"? Note: I am not talking about using SAGAs (could be part of a SAGA though but this is next level).
I have in the past used different approaches:
"Do nothing", i.e just try to send the message and hope it will be sent. Which might be fine in some cases especially with a stable message broker running on same machine.
Using DTC (in my case MSDTC). Beside all the problem with DTC it might not work with your current solution.
Outbox pattern
Using an orchestrator which will retry process if you have not got a "completed" event.
In my current project it is not handled well IMO and I want to change it to be more resilient and self correcting. Sometimes when a service is calling another service and it fails the user might retry and it might work ok. But some operations might require out support to fix it (if it is even discovered).
ATM it is not a Microservice solution but rather two large (legacy) monoliths communicating and is running on same server but moving to a Microservice architecture in the near future and might run on multiple machines.
This question is related to my earlier question.
I am using Mule 4.4 community edition, and I was looking through the various components available for JMS in Mule. I'm confused about JMS On new Message and JMS Listener. All of the documentation for listener seems to be talking about On New Message however the code snippets in this link shows a listener:
<jms:listener config-ref="config" destination="#[vars.destination]"/>
So it looks like they are both one and the same. If so, then I am confused as to why they show up separately in Mule palette as individual components.
When I dragged and dropped both of these components into their respective flows the underlying XML code still is about the listener.
They are the same. The display name of jms:listener is "On New Message." That's all there is to this. It is to maintain a consistency across different modules. If you check other modules like database, emails, SFTP, or any other module the XML DSL always has "listener" as its DSL element. The display name is different as they should be more descriptive then just saying "listener." For example, if you just say listener in SFTP one might think that it is also listening to deletion of files too, but it only listens to new or updated files and therefore it is more appropriate to name it "On New or Updated File."
Currently learning spring integration, I want to retrieve information from a MySQL database to use inside an int:service-activator, or an int:splitter .
Unfortunately, it would seem that most examples and documentation is based around the idea of using an int-jdbc:inbound-channel-adapter, which in itself requires a poller. I don't want to poll a database, but rather retrieve specific data based on the payload of an existing message originating from an int:gateway. This data would then be used to further modify the payload, or assist in how the message is split.
I tried using int-jdbc:outbound-gateway, as the description states:
... jdbc.JdbcOutboundGateway' for updating a database in response to a message on the request channel, and/or for retrieving data from the database ...
This implies that it can be used for retrieval of data only and not just updates, but as I implement it, there's a complaint that at least one update statement is required:
And so I'm currently sitting with a faulty prototype that initially looks like so:
The circled piece being the non-functioning int-jdbc:outbound-gateway.
My end goal is to, based on the payload coming from the incomingGateway (in the picture above), retrieve some information from a MySQL database, and use that data to split the message in the analyzerSplitter, or to perhaps modify the payload using an int:service-activator. This should then all be linked up to a int-jdbc:message-store which I believe could assist with performance. I do not wish to poll the database on a regular basis, and I do not wish to update anything in the database.
By testing using the polling int-jdbc:inbound-channel-adapter, I am confident that my datasource bean is set up correctly and the query can execute.
How would I go about correctly setting up such behaviour in spring integration?
If you want to proceed with the flow after updating the database, you can simply use a JdbcTemplate in a method invoked by a service activator, or, if it's the end of the flow, use an outbound channel adapter.
The outbound channel adapter is the inverse of the inbound: its role is to handle a message and use it to execute a SQL query. By default, the message payload and headers are available as input parameters to the query, as the following example shows:
...
I am using mulesoft ESB with Anypoint studio for a project. In one of my flows I am using one-way message exchange pattern to dispatch from VM (persistence file store VM connector) to JMS, both xa transaction enabled to avoid losing messages.
Consider a scenario where we send a message every time user updates his/her last name to ESB. For example, let's say user changes last name to 'A', but quickly changes to 'B', so final result is expected to be 'B'.
1) Is it likely that message 'B' gets processed before message 'A' in my case? and thus last name being set to 'A' instead of 'B'?
2) How do I avoid that apart from using 'request-response' MEP?
3) Is there a way to write unit tests for making sure order of messages being processed is maintained from VM (one-way, xa enabled) to JMS (one-way, xa enabled)?
4) How do I go about testing that manually?
Thank you in advance. Any pointers/help will be appreciated.
It's not likely, since your system would normally react way quicker than a user can submit requests. However, that may be the case during a load peak.
To really ensure message order, you really need a single bottleneck (a single instance/thread) in your solution to handle all requests. That is, you need to make sure your processing strategy in Mule is synchronous and that you only have a single consumer on the VM queue. If you have a HA setup with multiple Mule servers, you may have potential to get messages out of order. In that case, and if the user initially is connected using HTTP, you can get around most of the problem using a load balancer with a sticky session strategy.
A perhaps more robust and scalable solution is to make sure the user submits it's local timestamp on each request with high resolution. Then you can make sure to discard any "obsolete" updates when storing the information into a database. However, that is not in the mule VM/JMS layer, but rather in the database.
For testability - no, I don't think there is a truly satisfying way to be 100% sure messages won't come out of order during any condition by just writing integration tests or performing manual tests. You need to verify the message path theoretically to make sure there is no part where one message can bypass another.
So the model I need for my solution is as follows:
I need to poll the database and based on a result, create a request to the database for more data, get the response and pass it to a group of ports, for which based on a promoted property, only one of the ports will act.
It looks like this:
However, if you assign "Temp Out" to a send port group, the message is sent to all the ports in the group, irregardless of the filters set on each port. From my understanding, this is expected behavior (read here).
So I explored other options such as using Content Based Routing (CBR sample) like in the SDK. You can view this here.
I tried this and completely removed the orchestration (its really not needed). However, there are major routing/subscription errors, and upon further research, it appears that you can't do this if you have solicit-response ports. Some articles on that here. I pretty much have the same issue this user does.
In the end it doesn't matter to me whether I use an orchestration or not. However, I need a solution in which I can pass the message to multiple send ports, and I can have only one actually use the message and send. This is needed so that I can edit and add ports easily without having to modify anything else or hard code decisions into the orchestration.
You can use Direct Binding on the orchestration's send port to inject the message back into the message box db. Using multiple port groups, each port group can then directly subscribe to the desired message type and filter on promoted properties.
I found that the CBR example model does indeed work. The problem with routing were the subscriptions. If I was to subscribe a send port to a solicit-response port, I had to set the BTS.SPName (Send Port Name) filter instead of the BTS.ReceivePort filter. By doing this, the message was correctly filter through. You're answer would have worked too, but it requires using an orchestration which I was trying to avoid.