Get Identification/Configuration from server in Workflow

Question

I am working in a system where changes in lists will trigger a workflow, which will call an external system (a Java WildFly/JBoss server). That system will connect to Sharepoint through WebServices to perform some complex logic.

The issue I have currently is that, when our sysadmins updates the preproduction systems with a production backup (for testing, etc.), the workflows will be copied as well and so, if someone triggers the workflow from the preproduction server, it would contact my Java production server.

I could try filtering requests by IP, but I think it is always better to use higher level logic when available, so I was thinking if there was some way around this.

Ideally, there would be a way to put some data in the configuration of SP that does not get overwritten around (similar to Java JNDI), and that can be retrieved from the workflow as a variable; in that case I would write the Java server URL there (so the SP PRO server would have the Java PRO URL, and SP PRE server would have Java PRE URL set).

If that fails, I would settle to find some internal value that is unique to the environment (Server/Farm name/id?) that I can access from the workflow and include that in the message sent to the Java Server.

I am using SP 2007 server, and planning of using ILoveSharepoint control for calling an external WS (althought if the solution needs it, I can use a different component, call a REST WS or just a plain HTTPS request, etc.)

Answer 1

There's two ways I would consider doing this.

The first is that your workflow can get the site/web URL of the current item. From that you can test is it running on your production or preproduction environment, and call the relevant web service accordingly. The upside of this approach is that it is easy to implement, with only a minor change to your workflow logic, and it will migrate easily from production to preproduction without any manual steps. The downside is that you are hard coding URLs in your workflow and need to republish it if they change (or you want to add other dev/test environments).

The second way is to have a configuration list in the site your workflow is using, this can be easy as adding a custom list, and adding a text column called "value" or similar. Use this to store any values that change between environments, such as your web service URL. Your workflow can then look up these values as needed. The upside here is flexibility, you can copy your site to any environment, or if your web service URLs change, just update the config values. And once you have this pattern in place, you might find other uses for it too. The downside is that you will need to update the config values every time you copy from production to preproduction (but you could potentially script this if it becomes cumbersome).