I'm looking at adapting an existing application to add some composite application features to it, but I need to figure out how I can use components from different databases in the same application and not have to manually maintain the links on every installation we have.
The application consists of a bunch of databases, containing stuff like customer correspondance documents, contacts, sales statistics, order tracking, etc. I'm making a composite application to move the customer selection to a list on the left, and have different frames on the right that show a mix of the different information related to that customer pulled from the other databases.
However, separate instances of our application are installed in each of our sales units around the world, so we currently have around 100 discrete systems. This hasn't been a problem before, since we just update a template whenever we want to release a new version. But if I start putting components onto my composite application from other databases, they will be linked using the replica ID of our development database. Does this mean that I would then have to go to all of our production installations and change this to be the replica ID corresponding to that installation? Or can there somehow be a level of indirection so I can compute the database file name or replica ID? That information is always available in a profile document in each database.
Indirection in component URL (Bruce Mackenzie... 8.Jan.08)
Feedback number WEBB7ANK3G created by Bruce Mackenzie on 01/08/2008
. . How to calculate Links to NSF Compo... (Craig Wolpert 8.Jan.08)
. . . . Yes, thanks! (Bruce Mackenzie... 9.Jan.08)
. . . . Now this is an example of why notes... (Martin Lewis 9.Jan.08)
. . . . . . Then every db would have to be in t... (Bruce Lill 9.Jan.08)
. . . . . . . . Its the important special case of i... (Martin Lewis 9.Jan.08)
. . . . . . . . . . Special cases are just that special... (Bruce Lill 9.Jan.08)
. . . . . . . . . . . . That is probably appropriate comple... (Ben Langhinrich... 9.Jan.08)
. . . . . . . . . . . . This one is very common and I don't... (Martin Lewis 9.Jan.08)