We Keep Coding

Calling a Java webservice from C# .NET Core (specifically Workday). How to get xml attributes in the soap request

I am trying to call Workday's web service in .net core c#. The service was written in Java. I'm having problems getting xml attributes to show up in my soap request.
Example: What I want it to look like:
...
<wd:Usage_Data wd:Public="true">
<wd:Type_Data wd:Primary="true">
<wd:Type_Reference>
...
What it does look like:
...
<wd:Usage_Data>
<wd:Type_Data>
<wd:Type_Reference>
...
I cant get the wd:Public="true" to be there in the send request xml output. I am setting it in c#.
What I've done is create a WCF Service Reference to workday, and modified the Reference.cs to https://hr.dovetailsoftware.com/gcox/2014/06/13/getting-started-workday-web-services-using-c/, and tried playing around with the xml serializer a bit, but no luck. Other workday services that don't have any attributes work just fine.
I'm sure its a simple fix but I cant find it. I can post more code if necessary. Thanks

Figured it out. I think it's a Wrokday thing. Posting here in case of anyone else. You actually need to set the "Specified" properties.
phoneType.Usage_Data[0].Public = true;
//not good enough, you need to set this
phoneType.Usage_Data[0].PublicSpecified = true;

WCF Json serialization with service reference not updated

We facing a serious issue, but before saying that it's a bug in .net, I'd like to know if someone understand what's happening and why.
That's our configuration :
1 project DAL
1 project proxy
many others project that use DAL with WCF services as well.
They communicate with wcf services.
We have added some properties in one object in the DAL
We havn't updated service references in the proxy project.
(1)In the proxy with a breakpoint, we can see everything is retrieved properly except of course the new properties (service reference not updated => nothing abnormal)
The proxy is returning a JSON with WebMessageFormat.JSON ( we using the default provided serialization)
The response of the method called in proxy that call the (1) one in DAL is empty.
So it's definitely a problem in the JSON serialization ? no ?
Worst, we decided to changed from WebMessageFormat.JSON to WebMessageFormat.XML to see if the same happened, ==> It didn't
Last thing, no problem with other projects that hadn't been updated (they not using JSON ser)
Does someone have faced the same issue, or know why this is happening ?
Any help would be really nice :)
Thanks in advance to everyone and sorry for my english.

(This is not a definite answer, but a suspicion. However, this was too much to include as a comment.)
Note: I am assuming the following from your question (please correct/clarify if wrong).
The proxy project calls DAL through WCF and not the other way around. This would explain (1), and properties not updated through each layer.
A client calls the proxy project, which exposes itself through WCF too (this would explain the proxy project returning a WebMessageFormat.JSON response)
The issue here may be, as you say, with the serialization of the proxy response itself. While it's always advisable that you update your project references, in such a case it is possible that the generated classes are not mapping exactly to the response that they describe.
My take so far is that the changes in the classes had changed the internal responses in such a way that the references can no longer be mapped correctly to the response type, which is likely the ones from the mapped classes. The XML serializer is likely a separate implementation of the serializer, so it is likely that the JSON serializer has the problem failing on this specific case. You could check if this is the case by checking if there are any first chance exception in your internal output, or by adding debugging outside of your own code. This would likely confirm that the JSON serialization is facing an issue.
It may be actually be a bug, or an unsupported scenario when properties to map are not present.

I would advise that you use the DataContractSerializer with JSON if you are going to be consuming serialized JSON data from WCF (Set up your data contracts of course). I've ran into a few problems with JSON serializer, and realized it's a bit iffy with .NET
Another solution is to use this JSON serializer with .NET:
http://james.newtonking.com/json

Do you have object of type date or any other non primitive data type in the response data, I have faced problem when i try to include date object in the response data, for a quick work around I changed the
data type to string, it worked for me.

Forcing ASMX proxy to use XmlSerializer instead of DataContractSerializer

We were given external SOAP services that we have to consume in our project. All of these provide WSDL data, but a lot of them are not .NET services (most of them were written in Java). We have generated a number of client proxies with wsdl.exe tool. This tool does what it's supposed to do, it creates proxies for us to consume.
The problem appears once we try to call methods on these services using generated proxies. We intercept all SOAP requests for logging purposes and XML data looks different from the one specified in WSDL schema.
For instance, if a field is called "Name", our proxies will serialize it as "nameField". I guess this is because the property called "Name" uses a backing field called "nameField". Services on the other side obviously can't interpret this kind of naming convention.
This wouldn't be happening if our ASMX proxies used the old XmlSerializer, but for some reason they opt for DataContractSerializer, which completely messes up serialization and breaks compatibility between clients and services.
My colleagues have resorted to manually constructing XML data and then sending it with HttpWebRequest class. I think this is completely unacceptable in 2011, this is what automated proxy generation is for.
My question is: why is this happening? Why are our proxies using DataContractSerializer and thus ignoring all xml serialization attributes in the process? Is there a way to force them to use XmlSerializer once again?
We use .NET 4.0.

If you are using WCF the default is DataContractSerializer. And if the types do not have explicit [DataContract]/[DataMember] markers, then DataContractSerializer will use the fields, which sounds like what is happening.
To use XmlSerializer instead, add [XmlSerializerFormat] to your service. See MSDN.
You could also try adding [XmlType] or [XmlRoot] to your classes (if it isn't already there).

Getting methods from web service and their parameters programmatically

I'm playing around with WCF and wondering about the following. I'd like to be able to get a list of all available service methods and parameters associated with these methods.
Now, I've tried to work with the ServiceDescription namespace, but it seems flawed. For one .svc it works, for another it doesn't.
What would be an okay way to approach this? Any tips?

You could just download the WSDL of the webservice and parse that (it is XML, see http://www.w3.org/TR/wsdl) since the WSDL contains all information like interfaces/methods/parameters etc.
Some helpful resources including source code for doing what you want:
http://webservicestudio.codeplex.com/
http://wizdl.codeplex.com/
http://soap-sec.sourceforge.net/

How to create a web service that receives and sends xml based on xsd files?

I need to create a .NET web service that accepts xml, uses this to query a database, and then returns xml. I have been given xsd files for the request and response. Could someone point me in the right direction for where I start from or an example?
I haven't used WCF before so would prefer to use a simple asmx file to do this. I know how to get the data from the database, so it's the xml and web service bits where I'm lost.
I've tried googling this for a while but don't know where to start. Thanks.

The problem you have is that asmx and WCF are both code-first web service technologies. What this means is that you generally start with classes and the web service stack takes care of exposing your types as XML across the wire.
You are starting with a schema, which is not code. So if you want to use asmx/wcf you need to model your schema in code. You can do this by inferring a class structure from your schema using xsd.exe (or svcutil.exe for WCF).
Alternatively you can model your classes by hand based on the schema definition.
Once you have your classes then you can add declarative attributes to the code (See http://msdn.microsoft.com/en-us/library/83y7df3e.aspx for asmx, DataContract and DataMember for WCF). These attributes control:
how an incoming stream of XML is deserialized to a type when a service request is received, and
how instances of your response types get serialized to XML when passed out of your service
The problem with this approach is that getting your XML to validate against your XSD schemas will be a little bit hit and miss, as you cannot rely 100% on class inference from XSD, and additionally you may miss some fine detail if you are modelling it by hand.
Whichever way you do it you need to make sure that your request and response class instances cleanly serialize into XML which will validate against the XSD schemas you have been given.
Also look at a framework called WSCF-Blue which allows you to do contract-first web service design: http://wscfblue.codeplex.com/
Good luck, if you need any more detail about this please let me know via a comment.

From what I can understand, you need to build a webservice, which will accept XML as input, do some processing and spit out XML.
I assume you have a basic understanding of XML but dont know anything about XSD. In very simple terms, XSD is a document which is used to validate a XML file. Think of it a rule book for how XML file should be structed, you can read more about XSD from W3schools. Dont worry about the XSD to much right now. Get a few sample XML documents, which you need to accept as input and output. Build a console application to parse the sample XML file and get the results from the database. Then use the results to build the output XML by looking at the output sample XML. Once you have that completed, then you can use the .NET classes to validate your input and output XML from the XSD you have.
You can look at this answer to see how validation is done.
Once that is done, you can create your web service to return the XML as string.
Hope this help.