SourceHandler Writer null when calling informWriterError, fail to work - wso2

I deployed an API in EI. The API's main logic transformed a rest request to soap request and the calling a soap-based endpoint. Later I use a data mapper converting the response message to the format which I need.
But sometimes the endpoint went wrong and respond an error message, which made the data mapper parsed mistakenly and the main process went to the default fault sequence(I put a response mediator to the fault sequence), then I got an error log "SourceHandler Writer null when calling informWriterError".
After the scenario occurs again and again(about 200times in 5 minutes), the EI couldn't deal request any longer.
How can I deal with it?

I used the version 6.1.1 before, there is a bug https://github.com/wso2/product-ei/issues/650.
After upgraded to the version 6.4.0 release, everything is ok now.

Related

Cannot read message on ActiveMQ-queue when implemented in WSO2: "Cannot display ObjectMessage body"

I've just successfully implemented a JMS-message-processor in my WSO2-process. However, when logged in as an admin on the ActiveMQ console, I can view the stats of the queue but I cannot access the contents of the pending message. Instead, I see this error:
Cannot display ObjectMessage body. Reason: Failed to build body from content. Serializable class not available to broker. Reason: java.lang.ClassNotFoundException: org.apache.synapse.message.store.impl.commons.StorableMessage
Accessing the contents of a pending message is possible when using the RabbitMQ, so I figured it should also be possible with this message broker.
I've found solutions online, but they don't seem to be working, or perhaps they're out of date. Can somebody point me to the correct answer to solve this? I'm on WSO2 Integration Studio 8.1.0 and am using ActiveMQ 5.17.1.
It appears that WSO2 is using javax.jms.ObjectMessage despite the fact that there's a long list of reasons why doing so is a bad idea, including the issue you're currently facing, but I digress.
The problem here is that the implementation of the javax.jms.ObjectMessage (i.e. org.apache.synapse.message.store.impl.commons.StorableMessage in this case) must be on the classpath of any application which wants to deserialize that message. This class is not, in fact, on the classpath of ActiveMQ therefore the ActiveMQ web console cannot deserialize the message and display its contents (assuming those contents are human-readable in the first place). That's why a ClassNotFoundException is thrown.
You may be able to resolve the issue by putting org.apache.synapse.message.store.impl.commons.StorableMessage on ActiveMQ's classpath. Aside from that there's really nothing to be done.
I assume this is different for RabbitMQ because in that case WSO2 doesn't use the JMS API and uses the AMQP protocol which is not Java-centric like JMS.
Justin has explained the cause of the issue and as suggested you can try adding the class to ActiveMQ runtime and see whether it resolves the issue. This class is located in the Synapse-Core(synapse-core_2.x.x.wso2vXXX.jar). But remember although this may resolve the ActiveMQ UI issue, this message is not consumable by other systems unless they know how to deserialize it.
Let me add more details on why the message is serialized. Message serialization happens when you use the Store mediator, and when you store a message with Store Mediator it is intended to be only read by a Message Processor. Simply the serialized message can only be consumed by WSO2 Message Processors. In other words, Store Mediator and the Message processors are tightly coupled.
If message serialization is an issue for you. For example, if other systems are consuming the messages that WSO2 publishes you can try using the JMS transport to produce and to consume messages from ActiveMQ. Other than that you can also consider using JMS Inbound Endpoint to consume messages, which all use standard media types when storing the message.

Is there any way (like retry )to handle AWS SQS Sendmessage Failure scenario in WSO2 EI 6.4.0?

I am performing SendMessage operation in WSO2 EI 6.4.0 using AWS SQS Connector (V1.0.7).
Sometimes Message is not posted to AWS SQS Queue, got some ERROR/WARNING Message in Log mentioned below
ERROR Code from Log:
Error_code = 101506 or Error_code = 101508
Warning Message:
[HTTPS-Sender I/O dispatcher-2] WARN {org.apache.synapse.transport.passthru.Targe
tHandler} - Connection closed by target host before receiving the response Remote Address : host/ip
So whenever failure occurs, mediation will go to fault sequence , I'm just looking for some solution like retry .
Can i add some endpoint timeout error handling inside sendMessage template code and trying to rebuild the same?
Or else inside faulty sequence shall i perform same sendMessage Operation once again ?
Kindly let me know the feasible solution..
Did you try to use a Message Store and a Message Processor to implement a Guaranteed Delivery System? You have to publish the message to a Message Store. A Message Processor can try to post it to the SQS. If it fails, it will be added to another Failover Message Store. We can add the message to the original message store after some time with the help of another Message Processor. This way, it will keep on retrying until it succeeds.
https://docs.wso2.com/display/EI640/Guaranteed+Delivery+with+Failover+Message+Store+and+Scheduled+Failover+Message+Forwarding+Processor
If this solution is too complex, you can go with your second option where you call the sendMessage Operation inside the fault Sequence.

SAS Web services payload size - http 413 error

I have developed a stored process to receive an XML file as a response to a web service call and deployed it as a web service - something similar to the example here.
It is successful and working fine in receiving an XML file which is of ~100KB but failing to receive similar file which is about 3MB. The other system sending the response seems to throw the below error 
HTTP Response Code 413 for 'https://mystoredprocessURL'. I understand that this is related payload too large in size.
Could you suggest me how to configure the length of payload size that has to be received so that the stored process can receive a larger file. Tried to research but could not find anything relevant.
my first idea. I hope this helps, but that's just a hint:
SAS SMC-->plug-ins tab-->Application manager-->configuration manager-->
SAS Application infrastucture-->BI web services for java 9.4-->WebServiceMaker
-->Settings tab-->Attachemnt optimized threshold block.
Maybe the default size is 2048.

Twilio status_callback_event setting, not working for me, Python 2.7

Running this code below. It always successfully calls the number and sends the completed status to the callback url, but it does not sent any status updates before that. I checked the logs and there is only one call to the api made, which is the completed status.
Any idea why this wouldn't work? Documentation says these are valid status values: https://www.twilio.com/docs/api/twiml/twilio_request#request-parameters-call-status
Also on another possibly related note, setting the status_callback_method to "GET" doesn't seem to work either.
Relevant Code:
CLIENT.calls.create(to=phone_number,
from_=TWILIO_PHONE_NUMBER,
url=url,
method="GET",
status_callback=STATUS_CALLBACK_URL + call_uid,
status_callback_method="POST",
status_callback_event=["queued", "ringing", "in-progress", "completed", "busy", "failed", "no-answer", "canceled"]
)
I also used these as the callback events as defined here: https://www.twilio.com/docs/api/rest/making-calls#status-callback-event-parameter
status_callback_event=["queued", "initiated", "ringing", "answered", "completed"]
Unfortunately neither list works for me, only notifies me of the completed status
The python library uses the REST API whereas the page you have referenced is for parameters sent by Twilio to your server when you receive an incoming call.
The call back events are different, and there is no need to append the call_uid to your callback URL. Twilio will send that with the rest of the request.
Documentation that should get you on the right track is here
And... the answer is, try using the latest twilio library first 🙄.

WSO2 ESB launch on error sequence when fault received

I need to launch the on error sequence o generate a internal error when I receive a soap fault response in my orchestration. Something like throw an exception in Java.
An easy way is to set a filter in each sequence so that, when a fault tag is received, the onError sequence is launched. I guess there must be better ways to do this.
How can I make soap fault responses are treated like an error so that the on error sequence is launched?
This was not straight-forward until WSO2 ESB 4.5.0 (which is the latest release). There is new property introduced "FORCE_ERROR_ON_SOAP_FAULT" to get this done. See this post for a sample configuration.
In your proxy configuration, define the fault sequence..