I'm running an SAP PI/PO scenario and having a problem with finding the response message (the error one).
Scenario:
PROXY (class) -> SAP PI/PO 7.5 -> SOAP (wsdl)
The error when executing the scenario is:
Transmitting the message using connection
SOAP_http://sap.com/xi/XI/System failed, due to:
com.sap.engine.interfaces.messaging.api.exception.MessagingException:
Error encountered while executing mapping:
com.sap.aii.af.service.mapping.MappingException:
com.sap.aii.utilxi.misc.api.ResourceException: Could not determine
mapping steps for message 3b14b3f8-0860-11ed-a034-000001795062
The problem is that I cannot find the message (3b14b3f8-0860-11ed-a034-000001795062) in SAP PI monitor. It's the response message (who is causing the error), as the request message I did find in the monitor and it's correct.
Where I can find it? Why is not showing?
From what I read, this problem happens with several reasons, I just want to find this message.
The webservice works correctly, I test it in SOAP UI.
To find the response message (which contains the error), we have to first activate the Integrated Configuration log (it's not active by default).
To activate the log, we have to follow these steps (more info: https://blogs.sap.com/2012/11/06/message-staging-and-logging-options-in-advanced-adapter-engine-of-pi-73x/)
Go to "Advanced Settings" in the target Integrated Configuration.
Change the "Use global configuration" radio button to "Use scenario-specific configuration" in both, "Staging" and "Loging".
Change all "Staging" lists to "Store".
Change all "Logging" lists to "Log".
Save and activate.
Now, in the SAP PO monitor (Message monitor), by clicking the "Related Messages" option, we can see the response message error.
In this case, the error was:
<sap:Error xmlns:sap='http://sap.com/xi/XI/Message/30'
SOAP:mustUnderstand='1'>sap:CategoryXIAdapter</sap:Category><sap:Code
area='SOAP'>FAULT</sap:Code>sap:P1http://schemas.microsoft.com/ws/2005/05/addressing/none</sap:P1>sap:P2ActionNotSupported</sap:P2>sap:AdditionalTextThe
message with Action '' cannot be processed at the receiver, due to a
ContractFilter mismatch at the EndpointDispatcher. This may be because
of either a contract mismatch (mismatched Actions between sender and
receiver) or a binding/security mismatch between the sender and the
receiver. Check that sender and receiver have the same contract and
the same binding (including security requirements, e.g. Message,
Transport, None).</sap:AdditionalText><sap:ApplicationFaultMessage
namespace='http://schemas.microsoft.com/ws/2005/05/addressing/none'>ActionNotSupported</sap:ApplicationFaultMessage></sap:Error>
In which the Action was empty.
Related
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.
In the new Azure portal I see under "Metrics" section for an EventHub that there were many "Internal Server Error" events on a specific day. Is it possible to find out more about what could have caused it and description about those errors?
As the metrics for Event Hubs state about InternalServerErrors and OtherErrors:
InternalServerErrors: Total number of internal server error exceptions sent back to the sender or receiver while performing run-time operations. This type of error is due to either service-side or network problems.
OtherErrors: These types of errors are due to faults at the sender or receiver side, such as providing bad parameters, not enough credentials, or trying to perform an operation on a nonexistent entity.
I would recommend you log into azure portal, choose your Event hub, click "MONITORING > Diagnostics logs", then turn on diagnostics for collecting logs. For more details, you could refer to Event Hubs diagnostic logs.
I have a Integration Service that has 2 inbound fields (Login and Acao), both should be required, so I have created Business Object for each one, and at "Simple Type" section, I set the "Error Message" for these fields. When I ran the service by IBM BPM, and do not filled those field, the message is shown, but, if I call the service using SOAP UI, I just receive the error "Internal Server" and the message that I have set at "Error Message" is not showed.
I used "Error Intermediate Event" to catch the error and "Error end Event", but it still not work.
Whats is the best way to make a field required in a IBM BPM Service or how can I still throw an exception, but instead of "Internal Error" show specific message?
Kind regards
I'm not sure about your current IBM BPM version or edition and I'm assuming you are using only Process Designer.
I think it is not possible to throw an error the way you want. You may probably need to implement your Web Service (I'm assuming a WS is used to expose the IS) using IBM Integration Designer (IID), which is a little bit more complex but has a lot of flexibility.
In case that is not an option (only available in Advanced Edition), you can add an additional output variable to your current service to return (throw) the error:
Add a variable output as a String or any desired complex type
Use the regular End Event instead of your Error End Event
Include a script between the Error Intermediate Event and the End Event to map the error description to the new output variable
I am currently using WSO2 EMM 2.0.1, and platform configuration I use GCM,
I have follow the step in document, and already set the API key and Sender ID.
in the device I manage to get the GCM reg id too, but when I perform operation on EMM, at the console and log, I have receive this error (Exception occurred while sending the GCM notification : null).
I have try to find the solution through online, but I cant find any solution to solve this problem.
Here is a screenshot for the error:
Please advice and help, Thanks.
Since not much can be taken from the log, I looked into the code where the exception is occurring. Error in the log is possible generated from the line number 50 of the attached[1] code. In line number 48 it calls sendWakeupCall method[2]. As I can see in line number 75 and 76 of the sendWakeUpCall method, the returned status cannot be success. Can you ping the gcm server and see if it is reachable - ping gcm-http.googleapis.com
If so, you might have to debug here and see the issue your-self,
To debug, take a clone of carbon-device-mgt-plugins repository.
Switch to release-2.0.4 branch
Open the code using a preferred IDE.
Put some break points for sendWakeUpCall method
Edit your IDEs remote debug configurations to listen to a specific port and host(in IDE default 5005)
Start the server as - sh wso2server.sh -debug 5005
Now start debugging in the previously configured debug config.
You can find more details about debugging in the attached docs[3][4]
[1]. https://github.com/wso2/carbon-device-mgt-plugins/blob/release-2.0.4/components/device-mgt/org.wso2.carbon.device.mgt.mobile.impl/src/main/java/org/wso2/carbon/device/mgt/mobile/impl/android/gcm/GCMService.java
[2]. https://github.com/wso2/carbon-device-mgt-plugins/blob/release-2.0.4/components/device-mgt/org.wso2.carbon.device.mgt.mobile.impl/src/main/java/org/wso2/carbon/device/mgt/mobile/impl/android/gcm/GCMUtil.java
[3]. wso2.com/library/225/
i have wrote a Text Message Sender Program via JMS with C++ following.
tibems_status status = TIBEMS_OK;
status = tibemsMsgProducer_SendToDestination(
m_tProducer,
m_tDestination,
m_tMsg );
Suppose status == 0, this means only that Function has worked succesfull. It doesn't mean that my Text Message was sent succesfull
How can I ensure that my Message was sent succesfull? Should I get a ID or Acknowledge from JMS Queue back?
It depends on the Message Delivery Mode.
When a PERSISTENT message is sent, the tibemsMsgProducer_SendToDestination call will wait for the EMS server to reply with a confirmation.
When a NON_PERSISTENT message is sent, the tibemsMsgProducer_SendToDestination call may or may not wait for a confirmation depending on if authorization is enabled and the npsend_check_mode setting. See the EMS docs (linked above) for specific details.
Lastly, when a RELIABLE_DELIVERY message is sent, the tibemsMsgProducer_SendToDestination call does not wait for a confirmation and will only fail if the connection to the EMS server is lost.
However, even in the situations where a confirmation is sent, this is only confirmation that the EMS server has received the message. It does not confirm that the message was received and processed by the message consumer. EMS Monitoring Messages can be used to determine if the message was acknowledged by the consumer.
The message monitoring topics are in the form $sys.monitor.<D>.<E>.<destination>, where <D> matches Q|q|T|t, <E> matches s|r|a|p|\* and <destination> is the name of the destination. For instance to monitor for message acknowledgment for the queue named beterman, your program would subscribe to $sys.monitor.q.a.beterman (or $sys.monitor.Q.a.beterman if you want a copy of the message that was acknowledged).
The monitoring messages contain many properties, including the msg_id, source_name and target_name. You can use that information to correlate it back to the message you sent.
Otherwise, the simpler option is to use a tibemsMsgRequestor instead of a tibemsMsgProducer. tibemsMsgRequestor_Request will send the message and wait for a reply from the recipient. In this case you are best to use RELIABLE_DELIVERY and NO_ACKNOWLEDGE to remove all the confirmation and acknowledgement messages between the producer and the EMS server and the EMS server and the consumer.
However, if you do go down the tibemsMsgRequestor route, then you may also want to consider simply using a HTTP request instead, with a load balancer in place of the EMS server. Architecturally there isn't much difference between the two options (EMS uses persistent TCP connections, HTTP doesn't)
Producer -> EMS Server -> ConsumerA
-> ConsumerB
Client -> Load Balancer -> ServerA
-> ServerB
But with HTTP you have clear semantics for each of the methods. GET is safe (does not change state), PUT and DELETE are idempotent (multiple identical requests should have the same effect as a single request), and POST is non-idempotent (it causes a change in server state each time it is performed), etc. You also have well defined status codes. If you're using tibemsMsgRequestor you'll need to create bespoke semantics and response status, which will require extra effort to create, maintain and to train the other developers in your team on.
Also, it far easier to find developers with HTTP skills than EMS skills and it's far easier to find information HTTP that EMS, so the tibemsMsgRequestor option will make recruiting more difficult and problem solving issues more difficult.
Because of this HTTP is a better option IMO, for request-reply or for when you want to ensure that that the message sent was processed successfully.