The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
actually this came out of some university in Israel. That's why i made the mistake. Three students getting at best a D from me, because they got a 1/3 of what they did wrong, and I found out the hard way, by trying to code it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
As popular demand was crying out for "our own NuGet server", I thought TeamCity 2019 would be the obvious choice for this as it has a built-in NuGet server capability.
After more than a day I managed to get it working for our own built artifacts, but then was puzzled by how to host other .nupkg files on it.
No mention on the TeamCity website how to do this, only after much digging on the internet I found this:
But I guess it's clear that Team City at the moment doesn't offers full NuGet server capabilities which can be used to establish company's local repository
So I have to make this SOAP (1.1) service so some third party application can connect with our system and request data.
Fine, just tell me what the SOAP service should look like.
So I get a WSDL, which is invalid because two types with the same name have the same namespace (x3).
So I get a new WSDL and right after that a third because the other wasn't correct, which, after testing with the third party application (which I don't have myself), turns out to be incorrect because the namespaces don't match.
And I go back to the old WSDL, which still has the same type names.
I've just implemented the fifth WSDL with XSD's and I have no idea if this is going to work or not.
The version of the WSDL is embedded in the namespace, but apparently it's not possible to just give me that version of the WSDL.
I'm getting different versions in the namespaces, but I just changed the version to match that of the third party application and hope it'll work when I can test this stuff again.
The best part is that this is apparently a standard that's maintained by a work group and I'm the third person to implement this standard (about 10 years after the last implementation)
It's not binary, those are actual values (seriously)!
For example, the "A " somewhere at the end of the second line means quality A (the space is there because AA is also a possible quality, so that's two reserved characters).
The meaning can be deduced from the upper line, which is the definition and has codes with field length and precision.
Awesome that people created a standard that's so cryptic people actually think it's binary
Yeah, the message itself isn't XML, it actually predates XML.
The only thing that's XML is the (EDI) SOAP service that communicates the messages.
The service has a few functions, like requesting a list of all messages (without content), requesting a single message (with content), updating the message status and sending a message for others to pick up.
It's pretty difficult to generate that service if I can't get a proper WSDL though
We're building the SOAP service so that any customer with a specific application (which are quite a few) can receive messages automatically.
The only alternative is to take a subscription elsewhere, send them our data (in another simpler format) and they do the communication.
The subscription is fine for smaller businesses, but gets very expensive when you have lots of customers.
We also have customers who download the message manually (from a website or from an email) and then manually input the file into the application.
This industry isn't known for their modern take on IT
I know that the work group that maintains the message format also wants to move forward to XML or even JSON, so that would be a welcome change, but as long as the current message works no one wants to pay for that.