when a program throws an exception, the problem is not always in the code


it has been quite awhile since i last posted something. well although i could say that a number of things came up, i cannot say that they ate most of my time so as to prevent me from posting anything. truth is i could have posted a few lines but held myself back at the last moment for behind all the wordplay there was really nothing much to glean from them. well i’m no writer really but i’m writing here and i believe that if you want to be a good one, take it as a responsibility to feed your readers something sensible. surely there could be some sense in everybody’s life.

anyway, just last week i began testing this web service i created for our client. it was supposed to be utilized by the online banking system for the activation of various requests. this web service should run in the frontend and should call another web service from the backend (the mainframe specifically) for backend side request processing. during the development i had to work with stubs because i was working in our office. one can argue that i should’ve done it in the client’s development environment if permitted but i actually prefer working with stubs until i got most of the requirements done since the solution is easier to test that way.

so the time for testing the code came and i had to deploy the web service in our client’s development environment. it was pretty easy since i basically only had to change connection strings and a few more values in the web configuration file. i was informed that it was okay to input any value for the parameters of the web service method since there was no validation at the moment but when i did BAM! i received the error “Conversion from SOAP failed” when my code tried to invoke the exposed method of the mainframe web service and the mainframe’s transaction counter did not increment. i was cool at first thinking that surely i just got a line or two wrong. but when i found out that the exception was thrown by .Net’s wsdl.exe generated proxy when it called invoke, my expression was like “what the hell happened? what’s wrong?” i’ve used it before and i knew that the generated proxy is supposed to work with very little or no modification. still i tried to think of things that could’ve caused it like maybe i used the wrong wsdl file or i could not connect to the backend web service, etc. i tried applying the fixes i could think of but to no avail.

when i got back to the office, i was like “okay we’re unsuccessful but surely a lot of people could be encountering the same problem. if i could solve this, it will be something good to blog about” so i spent the remaining office hours researching on ways to connect to a mainframe web service and the common problems but surprisingly none of the google hits helped or even enlightened me. i thought i was doomed. i thought the best source would be the ones who previously worked with the web service but they are all not connected to our client now. another testing day passed and the problem remained unsolved until just last monday i tried inputting nothing in the parameters and the mainframe web service returned a different error code that was more expected. it was talking of invalid inputs. that gave me the idea that my problem was just a matter of giving the right inputs from the very beginning since there was very minimal modification done to my code. i went to the person in charge with the mainframe side of the project and asked for sample inputs and everything worked fine. well we’re not done yet testing the web service until the end of the defined transaction flow but it put end to the problem with the mainframe side of requests.

now this post was supposed to offer some sort of fix in a form of codes or instructions like i mentioned earlier. but since the problem was somewhere between the keyboard and the chair let me just leave an advice.

do not overanalyze.

we got as far as thinking of capturing packets exchanged between servers to check for discrepancies. it was a good thing that we had to postpone it because of the absence of the needed tools in the service. it would have been another failed fix in the list.

take time to consider all possible sources of the problem no matter how little or ridiculous they are.

in my case i completely ignored the possibility that the problem was caused by the wrong inputs. hadn’t i thought of giving the web service blank inputs, i wouldn’t have found out the answer to my problem.

lastly, use valid inputs whenever possible.

seriously, there’s no harm trying the right inputs especially when someone who knows them is just around.

hope you learned something from my experience. have a nice day!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s