The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
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.
Not only because I used it decades ago, but because of a recent contract (which lasted literally more than ten times longer than I was originally contracted for) which involved equipment used in airports -- so any new technology had to be cleared by roughly 9,785,276 governments, before it could be deployed.
EDI was just the tip of the iceberg. Anyone remember the fifty flavours of serial data? DOSKEY and DOS batch-script syntax?
Think you know everything because you can plug in an Ethernet cable? Think again, and get your soldering iron out.
Of course, I remembered pretty much nothing about the old tech, because I hadn't used it for somewhat more than a few weeks (which is about the limit of my memory), but relearning is a damned sight quicker than learning for the first time (especially if you have no frames of reference for it), so it was a job where kiddies need not apply.
I wanna be a eunuchs developer! Pass me a bread knife!
Hey, if they like old stuff, talk them into using PostScript, which does the job of XML but a thousand times better!
XML is like PostScript that's had its bollocks chopped off; kiddies only revere XML because they haven't used PostScript (and, of course, because it was "The Next Big Thing!", for a while).
And no, PostScript has nothing to do with adobe.
It was adobe's effing about (in their creation of Pee-Defecated-Files) that led to so many people abandoning PostScript, because they somehow managed to make it look hideously inefficient and slow, which it Shirley ain't.
I wanna be a eunuchs developer! Pass me a bread knife!
SOAP is fine. It's those dumb Java developers who build web services using all kind of Java-proprietary crap and shout "it works with Java clients" whenever someone points them to the specs they violate. I bet on the providing side you have a Java implementation.
Sorry for adding my rant to yours, you triggered some very angry memories (I spent too many hours trying to fix other parties' mistakes).
The Price of Freedom is Eternal Vigilance. -- Wing Commander IV
En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur.
(But the best thing God has created, is a New Day.)
-- Sigur Ròs - Viðrar vel til loftárása