Libraries in development repository vs. production repository

I just recently began to use libraries as our BPM development has been taking off lately. We have a development system and a production system (which I'm sure is common), but now I'm wondering what the best way is to target the development system with a library when the host processes are deployed to the development system and have the same referenced library target the production system when the process is later deployed to production.

I don't really understand entirely how libraries work -- if a process deployed to repository A references a library also in repository A, what happens if the process is then deployed to repository B? What happens if the library does not exist in repository B? Or does the process, now in repository B, somehow (across server boundaries) refer back to the library which is still in repository A?

Find more posts tagged with

BPM

Comments

Apperson_Rory

Update: I have just done some testing; I deployed a development process, which references a library in the development repository, to production. Amazingly, the library seems to be using the production system from the production process even though the library itself doesn't even exist in the production repository.

It's like the act of deploying the process somehow "resolves" all of the library operations and integrates them into the process before it gets deployed.

Aaron Van

The library is essentially added to your solution so it doesn't really matter where you get it from. I would be weary of not deploying the library separate for each environment though.

We run DEV, QA, STAGE, PROD and deploy our core library to each environment. We then point the solution to the env repository and update the library from there. While this is my recommended way, our hands are kind of forced since we have a web service connection that must be updated to the current environment.

...aaron

Apperson_Rory

Thanks Aaron. So what you're saying is that when you are about to make a change to a process and deploy it to your DEV environment for testing, before you do anything else, you re-point the process to the version of the library that resides in the DEV repository? That makes sense. In our environments, all of the variables (DB connections, etc.) are tied to the environment, so that shouldn't be a problem unless something gets hard-coded by mistake somewhere.

Aaron Van

Yup, precisely.

The one caveat to this is Metastorm is really finicky about how it updates it's libraries in the designer.

We find, more often than not, that you cannot simply rely on right clicking the library and clicking update after pointing to the new repo. We usually have to go to the repository tab, expand the deployment service, right click the library and choose "add this library to the current project". We then go back to the inventory tab and update again. We then verify that the web service connection has been changed.

We don't do this because we like extra work. I have seen in many cases after clicking update the connection string never changes as if the new environment was not chosen from options. The only way we know it worked is if you receive the warning message "This will replace the current version of the library. Do you want to continue?". Whenever that appears we know we have an updated library.

A little quirk with a reason behind it I'm sure, but something to watch out for when using multiple environments. I know Jerome uses independent PCs or VMs for each deployment environment. We don't feel as though that's necessary as long as your careful (or procedural).

Apperson_Rory

Thanks, Aaron. I have the benefit of having our dev and prod environments completely separate -- separate machines with their own web servers and separate databases, obviously. As for the connection strings, I'm using ODBC DSN's -- the dev server points to the dev DB and the prod server to the prod DB, so when I tested it this morning as I mentioned earlier, it worked seamlessly. I was a bit surprised that it worked right away, but that was because I didn't understand that the library gets added to the solution; I thought it referenced the library "at run time".

Jerome Pearce