Identify Operation on the basis of xml content posted in WCF Service without including operation name in Url - wcf

How to identify operation from xml content posted to WCF Service Url?
Suppose WCF Service Url is http://single.mat.nn.com and client dont want to include operation name in Url.
Problem is to identify operation on the basis of xml content posted .
I am not able to find any solution for this problem. Is it feasible to do configuration in WCF Service that can identify operation method on the basis of xml content posted to WCF Service URL.

One of the scenarios possible in Extending Dispatchers is:
Custom Operation Dispatching. Users can implement dispatching on something other than action – for example, on the body element, or on a custom message property. This can be done using the IDispatchOperationSelector interface.
Implmenting IDispatchOperationSelector will give you access to the incoming message to parse and decide which method you want to forward the request to.

The SOAP web service based on the corresponding method of the SOAPAction field request in the HTTP request. See the screenshot below.
The SOAPAction field and the method section in the request body can view the operation name of the specific request. If you want to recognize this value, we can intercept the SOAP message through the following two interfaces and get the value of the field.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/extending/how-to-inspect-or-modify-messages-on-the-client
https://learn.microsoft.com/en-us/dotnet/api/system.servicemodel.dispatcher.idispatchmessageinspector?view=netframework-4.8
these two interfaces could capture the SOAP message during the communication. We could retrieve the field value and modify it.
Feel free to let me know if there is anything I can help with.

Related

Handle JSON calls in WCF to single URL with method name contained in request body

We are replicating an existing service and need to offer the exact same contract.
Requests are posted to a single URL with the method name contained in the request body.
For example the request body of a call to LoginService.Login:
All calls will be made to: http://example.com/json
{"id": "","method":"LoginService.Login","params":{"aUserID":"flip","aPassword":"1234-613E-1240-C55D-9853F37A41B2"}}
How can we accomplish this within WCF? The response should also be JSON.
I didn't know what I wanted was called jsonrpc. Luckily somebody already tackled this problem:
Implement JSON-RPC in WCF

Action vs Reply action WCF

What's the use of action/reply action for service operation in WCF. So far, what I've understood is; action is used by WSDL to identify the service operation to which the message from the client belongs and in return reply action is used by service operation to identify the caller to which reply message belong --> Please correct me if I am wrong with this!
Now, I want to understand; what's the real use (apart from handling anonymous messages by using aster ix [*]), I mean this could well be handled internally by WCF instead of exposing it to the developer.
Also, why is action and replyaction required at all? I mean, we already have a name property for the service operation to identify the method and when I call Proxy.SomeMethod() then somemethod is already mapped to the Name property and it should be enough to identify the destination method for the message and similarly the replyaction. Please clarify.
Can I please get a simple real world scenario/or link to that to understand Action/ReplyAction in real life.
Many Thanks.
Actions are part of the various SOAP and WS-* specifcations.
So the first point is that this is not something unique to WCF it is a standard part of the specification you need to support if you want to have interoperable web services. They are used for message routing and other message handling functions.
Second, WCF DOES manage these by default. You only need to specify them yourself if you wish to customise or manage them in some other way. E.g. WCF will automatically generate them into the WSDL for you. WCF will also use them by default when it is selecting which operation to invoke for an incoming message. Again, WCF provides extension points to customise this behavior if you require.

How does WCF Decide which Operation to Dispatch To?

I'm building a WCF SOAP application. The WSDL file has numerous operations of which many have the same argument type. The WSDL file defines all soapAction attributes as "''". When I try to start such a service WCF throw an exception saying that soapActions have to be unique.
After some googling I'm even more puzzled than before. I used SOAPUI to create a mock service with two operations which take the same input type and without the soapActions defined it always chooses the same operation. When the actions are defined it works fine.
My questions are:
Can you make a WCF SOAP service without unique soapActions (actually leaving the soapActions "''" as defined in the original WSDL)?
How can a service choose the right operation without the soapAction defined?
Edited:
I'm not in control of the WSDL. I'm using the WSCF.Blue tool to create a service stub from the WSDL file. I might be able to modify the WSDL, but I want to see if there is some possibility to leave it as it is.
It is not very clear from your question but I suggest you are building service based on some defined WSDL, aren't you? WCF by default uses SOAP action because it is required part of WS-I Basic Profile 1.1 offered by WCF services with BasicHttpBinding. WSDLs with empty SOAP actions are used when the action is defined by root body element.
WCF samples provides example of custom DispatchOperationSelector which is able to route messages to operations by their root body element. This is probably what you need to add to your service so that clients based on provided WSDL can call it.

How add cutom header in WCF with dynamic user values to every call?

I am consuming one java webservice with WCF client.
I want to pass user related information to service in header. I have aleady gone to through thread
How to add a custom header to every WCF calls?
I have implemented IClientMessageInspector interface with BeforeSendRequest() method. Now, I want to pass user related information in SOAP header like Oraganization, which may differ for every user. I have all this information in my ASP.net application, which uses this service.
Is there anyway I can pass user related information to this BeforeSendRequest() method from asp.net session and build Message header before sending any request?
There are few options
Put the information in Session and retrieve it in BeforeSendRequest
Put it in HttpContext.Current.Items and retrieve it in `BeforeSendRequest'
Use Thread Local Storage (http://msdn.microsoft.com/en-us/library/6sby1byh.aspx)

WCF auditing/logging

I need to provide non repudiation in my WCF services and want to store all my incomming SOAP requests into a SQL server DB with signature/security data and all the envelope stuff.
This way, when a problem occurs, we can tell to the client "Hi, THIS is your signed message" exactly as you wrote it.
To do this, I need to store a relationship between the SOAP envelope XML's and my persisted bussiness objects/transactions.
Example: THIS is the SOAP Envelope used to add Customer ID=4567 to my Customers datables.
I need to establish a link between SOAP envelope and the bussiness transaction performed by my app. Storing ##identity of the logged message could be a solution. But, where do I put it? In the SOAP Body? Keep it in memmory?
I've reading about logging in WCF and wrote a Database Logger that inserts into tables the log info instead a text file, but i don't know how to link this data with the parsed/deserialized bussines datacontract object that arrives to my WCF service's method.
I don't even know if this is the rigth approach!
Any pattern/tip/hint/tool/help would be appreciated.
Thanks.
If you have enabled the message logging feature of WCF (http://msdn.microsoft.com/en-us/library/ms730064.aspx), you can write a custom listener, and there add all the logic you need. To write a custom listener you only have to implement the TraceListener interface (fairly simple) and then configure WCF to use it, adding it to the listeners section inside the system.diagnostics, replacing the default listener.