Lisa's company needed to add some custom functionality to a third-party application- IniERP- which was made easier by the fact that the company had a SOAP web service to interact with. The vendor supplied Java sample code for building the service, so it was trivial for Lisa to build her own code to automate those interactions. And everything went fine, and her users were happy.

So fine, and so happy, that other teams heard: "there's a way to integrate your applications into IniERP." Every department in the company had business processes which touched IniERP on some level, so "Lisa built a thing which lets you do this!" got her a lot of emails.

There were issues: there was only one "service" account configured by the operations team, so anyone wanting to interact with the service needed to share an account. For that reason, Lisa resisted sharing her solution until ops made a better way to provision accounts, but demand was so high that management pressured her into sharing her code, the documentation, and the credentials.

And despite the obvious problems, even that went fine. Mostly. Because most of the teams either had the IT staff available to do the work, or realized this was beyond their technical skills and gave up. Then there was Bert.

Bert was a developer on one of the web teams and wanted to integrate their applications into IniERP. So Bert fired up his IDE, hit copy-and-paste, and went to town. Accessing the HelloWorldWS testing service went great, and with that confidence Bert went straight on to accessing the real web service- and that didn't work.

Bert sent Lisa an angry email, complaining that her samples didn't work, that obviously she didn't know what she was talking about, that he'd wasted three days fighting with her bad code, and that she shouldn't run around telling the company that she was so smart if she wasn't able to release code which worked. "You shouldn't release what is essentially pseudocode and then tell people you've fixed their problems!"

Politely, Lisa offered to take a look at Bert's code, and see if she could spot the issue. Bert resisted, at first, but eventually relented with the comment: "It's the code you supplied, so if it's wrong, that's on you."

There were a few obvious problems in Bert's code. The first, and smallest one, was that in a few spots instead of copying a constant declaration and its value, he just created a constant and set its value to its name. That was weird, and certainly enough to explain why his code wasn't working, but it actually wasn't the reason why it wasn't working.

You see, Bert was a PHP developer. He was building a PHP application. But he copy/pasted Lisa's Java code into a PHP file, and then remangled it until it was executable PHP. Much of his frustration was rooted in the fact that her code didn't even run when he copy/pasted it into a PHP file. Somehow, that mangling had gotten it into a state where it could access the HelloWorldWS, which didn't have any authentication on it, but also broke the authentication code so that secure services wouldn't work.

"Um," Lisa explained, "my code is in Java. It's not PHP."

"Java, so like, I can embed it into the front-end of my page? But wouldn't that mean putting the credentials into the HTML or JS files somewhere?"

In the end, someone on Bert's team reached out to the vendor, who could point them to some PHP code examples for what they wanted to accomplish. It took a little longer, but Bert's team got what they needed. Bert, however, never quite understood what Lisa was talking about.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!