|
|
Rank: Newbie
Joined: 12/7/2008
Posts: 6
Location: UK
|
Hi All,
I have built a web-service on my local pc and this is working fine - now want to deploy it onto a server. The problem is that the compiled web-service appears to be referencing the database on my local pc.
Is there any approach that will get me round this? Can you somehow have a parameter that will take the database connection details?
If this is not easily possible then it sounds like I will have to reconfigure and re-compile the web-service for each server that it is installed on.
Hopefully I'm missing something
TIA
;-)
|
|
Rank: Advanced Member
Joined: 6/16/2006
Posts: 486
Location: AT
|
You can set the runtime database parameters in the properties dialog of the database component (data source, catalog, user, password, JDBC (Java)/ADO (C#) settings).
|
|
Rank: Newbie
Joined: 12/7/2008
Posts: 6
Location: UK
|
I still don't think that is an ideal situation - if you had 10 different environments you wanted to deploy a webservice to - you would need to compile a different set of files for each environment. It would make things a bit tricky.
Obviously you 'could' modify the web service to read the connection string from a parameter - but I was looking for a more streamlined build process which didn't require the source code produced by mapforce - maybe modifying the source code templates might help.
You would still need to modify the wsdl's for the specified server whatever the scenario I imagine.
|
|
Rank: Member
Joined: 6/28/2009
Posts: 10
|
Hi,
if you create java code you can find in the "ProjectName"WebService.class file the connection parameters (search "getConnection").
The file is in the com\mapforce directory inside your code output directory
I never tried this, but i think is the right place to work.
I hope I have been helpful
|
|
Rank: Advanced Member
Joined: 12/13/2005
Posts: 2,856
Location: Mauritius
|
Did you try to use Global Resources instead of direct database connection? They will allow to switch a destination with a single combo-box.
|
|
Rank: Member
Joined: 10/7/2011
Posts: 11
Location: Akron, OH
|
vlad wrote:Did you try to use Global Resources instead of direct database connection? They will allow to switch a destination with a single combo-box.
That works only until you generate code. Then the connection strings are hard-coded.
|
|
Rank: Member
Joined: 10/7/2011
Posts: 11
Location: Akron, OH
|
Update: Altova has ignored this problem for years. With MapForce 2018 and later, they have made the problem even worse. Not only is the connection string hard-coded, but it generates the connection string constant over multiple source lines. That makes it nearly impossible to do a simple search & replace. Without advanced editing - the kind that can parse C# or whatever language you're generating - editing must be done manually and cannot be automated.
Whenever I make a change to a single mapping or library function, I have to manually edit about 20 files on average to fix the cursed connection string, turning even a trivial 5-minute change into something taking 30 minutes or more. This is a giant stain on an otherwise decent product.
Using a Global Resource doesn't help either. The connection wizard tries to validate to a live database when saving, so it prevents you from creating a simple dummy connection string that would be easy to replace.
For the record, I am no newbie as I'm labeled in this forum. I have been using MapForce regularly for over five years and still gotten no satisfaction with Altova on this issue. This is a design flaw they haven't even tried to fix.
The extreme difficulty of changing or parameterizing connection strings when using generated code is and has always been a major pain point when using MapForce.
|
|
Rank: Advanced Member
Joined: 6/16/2006
Posts: 486
Location: AT
|
eeaglehouse wrote:Whenever I make a change to a single mapping or library function, I have to manually edit about 20 files on average to fix the cursed connection string, turning even a trivial 5-minute change into something taking 30 minutes or more.
As far as I remember, the connection strings only appear in the small wrapper class that calls the actual mapping - so maybe it's more convenient for you to just replace that whole file with your own after generating the code?
|
|
Rank: Member
Joined: 10/7/2011
Posts: 11
Location: Akron, OH
|
that wrote:eeaglehouse wrote:Whenever I make a change to a single mapping or library function, I have to manually edit about 20 files on average to fix the cursed connection string, turning even a trivial 5-minute change into something taking 30 minutes or more.
As far as I remember, the connection strings only appear in the small wrapper class that calls the actual mapping - so maybe it's more convenient for you to just replace that whole file with your own after generating the code?
That's only the initial call to the mapping. If you have functions that access the database, the generated source code for the connection string are in each function module, too.
Actually, I think I may have stumbled onto a workaround. Instead of replacing the entire connection string assignment statement, I have inserted a parameter (a function call to another module, in my case) and a dummy assignment in front of the connection string. The dummy assignment preserves the syntax of the original, innappropriate assignment so the compiler doesn't complain, but I still get my own connection string at runtime.
So the original statement lines:
Code: conn.ConnectionString = "generated, inappropriate, confusing, huge, and useless"
+ " connection string";
Become:
Code: conn.ConnectionString = Global.GetMyRuntimeConnectionString(); object ignored = "generated, inappropriate, confusing, huge, and useless"
+ "connection string";
Sometimes rants release enough pressure to come up with a more creative fix. It's a pity that it had to come to that.
|
|
|
guest |
