We are currently trying to improve our pipelines by adding error paths and are having problems with the JMS Consumer snap.
Unlike other snaps, like the SQL Server snaps, where a connection failure is routed to the error path, a connection error on our JMS snap does not trigger the error path and fails (see attached image).
The snap works just fine usually, I was currently trying to trigger an error by using the wrong password to see if the error path was working correctly, because error caused on MQ issues needed to be foward to a different team than the team managing the rest of the pipeline in production.
My issue is not the error itself but the fact that it doesnt go to the error path and instead fails right there.
In comparaison when i use the wrong SQL password on the SQL snap it triggers the error path correctly :
Preview not necessarily suggests that there is no error in the pipeline. Preview is for the random 50 records (this depends on your settings too as seen in the snaps below:
Let’s assume, your settings is set to 50 documents in preview, if those 50 ran successfully, the preview will pop up Green but there is remaining data (i.e. raw data count) which will come into effect after clicking “Execute Pipeline”
Great, can you double check whether child pipeline has been properly called in the pipeline execute?
Moreover, are you wanting to pass any parent pipeline parameters in the child pipeline which hasn’t been declared in the parent pipeline?
Hum… sorry but i feel we are not focussing on the issue i’m having. I’ve updated my first answer to make it more clear (also english is not my first language sorry if i’m confusing).
My issue is not with Execute Pipeline failing or such, it’s that the JMS Consumer Snap don’t go to that error path. The Audit after works just fine if i use the good SQL password, i was juste trying to show quickly a similar issue having a different consequence but i have no issue with either the SQL or Execute Pipeline.
So are there some errors type that won’t trigger an error path ? Is this maybe on some snaps only ?
Please don’t apologize, you’re not confusing and it doesn’t matter if English is not your first language. This space “Community” has been build to help each and every individual irrespective of their locations, work titles, language, programming languages they use, etc.
I was trying to understand whether all the snaps have been configured correctly along with the account so that we can drill down to a single point of failure. Well, I’ve already tagged the SME’s on this thread so they might be able to help you as they have more exposure and visibility to such issues.
Please open the Pipeline Validation Statistics, show more details for the error in that snap, and post the details here using the preformatted text feature of the editor (the </> icon). The stack trace will help us identify the cause of this issue.
Here is the error i got. In this case i was specifically using the wrong password to trigger an authentication error.
An error occurred while creating the consumer
Please verify if the provided properties like destination, message selector and subscription name are valid
JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
com.snaplogic.api.ConfigurationException: An error occurred while creating the consumer
Caused by: com.snaplogic.snap.api.SnapDataException: An error occurred while creating the connection from the connection factory (Name: CDP_MQ_APP1)
... 11 more
Caused by: com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for queue manager 'TAAPP1' with connection mode 'Client' and host name 'CTAMQS1.LACAISSE.COM(1417)'.
Please check if the supplied username and password are correct on the queue manager to which you are connecting. For further information, review the queue manager error logs and the Securing IBM MQ topic within IBM Knowledge Center.
... 23 more
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
... 32 more
Reason: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035'
Resolution: Please verify if the provided properties like destination, message selector and subscription name
Error Fingerprint = efp:com.snaplogic.snaps.jms.jP6OsCuR
Error Fingerprint = efp:com.snaplogic.snaps.jms.WukNlqv9
Error Fingerprint = efp:com.ibm.msg.client.wmq.common.internal.w7ghFJBL
Error Fingerprint = efp:com.ibm.msg.client.wmq.common.internal._mz1O6W-
The snap is throwing a ConfigurationException showing that the authentication failed. Most snaps handle such exceptions by immediately failing rather than writing the error to the error view. The error view is typically used for a document-specific error that may not occur for the next document. But authentication errors aren’t really appropriate here, since the only way to really “handle” them is to fix the configuration of your account and run the pipeline again.
If the SQL snap isn’t behaving this way when using an account with a bad password, then I’d say that snap is not following our normal error handling conventions. If you gave it 1000 input documents, you’d see the 1000 copies of the same error on the error view, as it would attempt the same failed authentication over and over. That doesn’t seem ideal.
When you ask “Is there a way for us to catch those errors without ending with a failure?”, what do you have in mind? If the account is misconfigured, isn’t ending with a failure what you would expect?
Thank you very much for this answer ! You gave me a better insight on how things work.
And yeah it actually makes a lot of sense that i’m not catching this error. Yet at the same time being able to handle an error path and stop the pipeline instead of failing is quite different.
For the JMS snap I want to be able to direct any issue with MQ directly to MQ team cause i have no hand in it. Most issue these days are actually about a down with the MQ but i was doing quick testing on my side only so i tried with an auth failure instead. I’ll contact the MQ dev team for integrated testing to see if i can reproduce the exact error and check how snaplogic responds to that.
Regardless of the error/snap having an issue and of what kind, I wanted to be able to STOP the pipeline after sending a notification / logging the issue, instead of ending in a FAILURE (which is also a stop but abrupt). That’s because of how my organisation poorly deals with failures in Snaplogic i guess. Since we’re a big org with several teams using Snaplogic, right now it takes several hours for my team to be made aware of the failure of one of our pipeline in production and then i need to dig in the dashboard to find more info and it’s really not an efficent process. With an error path i can make us aware directly and with more specific info depending on where a problems occurs.
@Lydia If you want to explicitly stop your pipeline after send some action (logging/notifying) you can use EXIT snap and config till how many no of document it accept like 1 in below pic. You can also customized you error message on exit error message filed. If you config that pipeline as task and select notification in case of failure, people will get snaplogic platform generated mail with your custom error message.
Configuring through task the notification does work in this scenario. Does this mean that this is expected to work like this only. Because clearly there is a difference in behavior between MySQL Snaps & JMS Snaps.
Is this expected?