hi everyone,
since 3 months i am connected almost every day in this forum to learn and to solve some errors that happens when i’m developping. for all this things, THANK YOU
Now, my “problem”,
i’ve created a flow service on an IS and generated a .wsdl. Then I use it to generate a “Web Service Connector”. Everything is OK, and I can use my webservice remotely. but…sometimes…after a short time of inactivity from the IS (or the webservice), I receive a soap-fault “Access Denied”…If I relaunch my service everything is ok. I don’t understand why this happens sometimes…
has anyone any idea ? inactivity problem ?
may be there is an option somewhere
(I know i can use the ACL to enable Anonymous access but i want to know why this happens :rolleyes:)
Your first invocation of the service creates a new IS session. That session times out after 10 minutes (or whatever you configured at the server level). When you invoke the service again after some period of inactivity, your client presents the cookie returned in the first invocation which is referencing the expired session.
Some clients have an option to reset cookies which avoids this behavior.
Why are you invoking a web service provided by Integration Server over soapHTTP? Just build your soap request object and call the Flow directly. No need for the extra overhead for an internal invocation.
may i’ve not clearly described the environnement :rolleyes:,
but i have two IS on two pcs, one is the client and the other the web service; so it’s not an internal invocation.
As you cannot do it from Advantage,you can send a requesting email to support@webmethods.com along with your company contact details etc…then they will reply you back with that requested Fix.
Also, I’ve observed in the past that if the same webservice is invoked repeatedly and if there are lots of sessions created by the client within a short time frame, some requests get dropped. It was extremely hard to debug this issue, but we finally discovered that the default session management that we were licensed for (by default) were only a certain number of sessions and hence some client requests were dropped. Another thing we also noticed that these sessions were being left open and did not timeout even after some time. ( Is->Sessions) There were a lot of sessions since there was one for every request.
The fix to this was to make the service stateless and to make it a custom soap processor (instructions on custom soap processor in web service developers guide). Since the custom soap processor does session management differently.