04-08-2010 02:31 PM
I realize the subject is a little broad so I'll see if I can explain a tad bit better:
I am on an internal network with a dedicated act server running ACT! Premium 2010 that all the clients connect to with a PAD file and link up--that's fine.
We try not to require an install of the client on every machine which is why most of our users use the Web-based ACT client--which, once again, works fine.
The problem lies with external application developement; I would like to make a client that can effectivly communicate with the ACT database without the need of a client to be installed. For starters, running around to more than a dozen computers and updating them is tedius at best. Secondly, these are already loaded up with (amoung other packages) one particular application that has it's own 45 minute install and a lot of files. Any resources I can free up (albeit disk space, resources from the absense of a local SQL server, and (in the long term) backup image space from weekly archives, etc.) is all the more preferable.
Now, that being said I ran across a problem as mentioned in a couple of other threads with the occurance of Act.Framework.ProductMismatchException firing at LogOn. Based on what i read the solution seemed logical (but undesirable)--the licensing server is necessary so that the SDK knows that it is connecting to a premium database. So I installed the client and (with no source code changes) I was able to connect flawlessly.
I guess what it comes down to is there at all a possibility to use the SDK without a client present? I'd *love* to avoid a client install at all costs, so whether there is a flag I am missing in the framework or just a license server installer i can run with my application it would be a beautiful thing. It seems like it's possible as it's my understanding the web server doesn't require a client install so there is already the presence of a licensing serve ror work-around to connect to apremium database without a client. How do I access such a feature?
Any help at all would be appreciated. Importing DLLs with an installer package and adding a "ACT License Server" requirement is simple enough to do, just how do I go about doing so?
Thank you for any help you can provide.
04-10-2010 12:01 PM
Several views but no answers? Rough.
Upon further thinking i was considering making a WCF service that ran on a single machine and use that to route queries through so i only have one machine to update; is this a viable solution? I found a couple posts from modertors in regards to "act will not connect without a client", but as I mentioned I just dred putting the client on all the machines. If anyone has a work-around or anything I would very much appreciate it. We run ACT with about 30 clients and the Web Interface has taken the strain off updating and maintainance, but I would hate to add the client for the sole purpose of using it's licensing service.
Any input, even in regards to "You could do it for $x if you hire one of our developers" would be appreciated.
04-14-2010 01:12 PM
So, I have decided to use a WCF service to get around the licensing service. I've gotten as far as I expected (with a serialization error on the ACT objects). Now, I guess the question is this: what information is necessary to pass over the contract to allow for the service to grab the object again (in a different call) and still know it's an ACT object? worded differently, how do I get around the lack of serialization on an ACT object?
I assume in the ACT object is a unique ID (if not a connection handle) so when you make a Contacts.GetContact call and get (a Contact/Contacts) back the library can still reference it for an .Update() call. But what can i do to persist this back and forth over the data contract?
Someone has to be seeing these posts. With 80+ views a Mod (or several) had to have reviewed these. Is there anything I can do? If you guys aren't going to support the ability to avoid an entire client install, can't you at least help with bypassing/working around the problem? We run premium version with 30+ clients, it's not as if we don't patron your product.
Thanks for any advice,
04-20-2010 03:42 PM
And now I am getting Version Mismatch. Shouldn't pulling the Act.Framework.dll out of the Act for Web (which clearly works) and putting in your application work fine? Frusterating. I'd really appreciate a more detailed exception than just throwing a generic ProductversionMismatchException("Error in the application").
I am running v2010 of ACT, and upgraded to the service pack. I assume that's the issue and the DLLs on the CD are no longer valid. is that an accurate conclusion?
04-27-2010 03:53 PM
I've given this some thought - Are you just trying to integrate data to ACT! via this other application?
There's 2 examples on the dev downloads forum of building a web service against ACT! to publish data to a widget and to an iPhone, given that you are already deploying the Web client this seems like the most logical approach. Check out those examples of building a web service to access contacts and activities.
Going the route of trying to just get enough of the framework assemblies down to a client is probably a fruitless effort - I don't believe we've done any min package install research so I don't know what cross dependencies exist for this.
05-07-2010 09:56 AM
Now what about pushing updates back? I can get data fine, either by extracting it at the WCF level and populating a custom serializable object or by a single field, but I'd like to have the program calling the WCF be able to push updates back. Having ACT classes serializable would be amazing, just wish they had thought about it and integrated it.
I'd like to see the Contact/Note/Company objects like LINQ objects where they retain the table's primary key, allow you to modify the object however, then push the update(s) back to the database--but also across a service boundry.
To say the least, it's tedious to be extracting the ACT object in to a custom [Serializable] object (reflection or not), allowing the end-client to adjust it, then having WCF re-locate the ACT original, do another "copy back" over from the custom object pushing changes, then calling Update. ;-\
05-25-2010 09:36 AM
Here is a thought. I am not in a position (yet) to experiment but you may be. The thought is based on the recurring statement I see that ACT needs to be installed on the machine where the app is connecting to the ACT server even if the machine doesn't need the native ACT functionality.
What would happen if you used a test machine and installed ACT as suggested and then developed your client application on that machine with Visual Studio and then created an install package for your client application? Would VS be smart enough to recognize the ACT components that would need to be included in the install package and roll them up into the installation package?
05-27-2010 06:34 AM - edited 05-27-2010 06:38 AM
The problem lies with the licensing service that comes with the client, not the libraries themselves. ACT! requires a license manage for databases that use the premium version, and therefore you need the client installed (well, unless you want to go through and trace what it's looking at, what registry keys it may use [if any], file checks, etc).
I have put the project on hold and have just been sticking with performing the lookup in our ERP, which graciously uses a SQL back-end. Though it would have been nice if I could have a single-entry that the engineers enter the contact's data once and it gets pushed in to ACT!and our ERP (as the ERP is responsible for quoting and contacts entered there don't usually make it to ACT! until order processing for time-saving purposes. There is an ERP plugin, but once again not worth it in the interest of time). But the pitfall is ACT! would need to be on each individual's computer, thus my reasoning for WCF.
This was more the "opening" idea, with more complex business logic to follow, but have to start somewhere.If anyone has ever made ACT! perform well over a WCF I would be very appreciative to hear it. Should I eventually get it up I plan to return with the solution(s)/steps taken as to help others.
05-27-2010 07:17 AM
I was afraid it would be something like that. Thanks for the feedback.
I'm having the worst time getting a VB project to talk to ACT! See a post to follow soon on a whole new error.
05-27-2010 08:05 AM
OK I think I understand better what you ar trying to do now. It seems you are trying to create a custom program that can access/update ACT! but not be dependant on a local install of ACT!. I'm guessing you're loking at building a windows forms application in .Net to do this.
Architecturally speaking, even if you could get this to work by serializing ACT! objects this is not a particularly good approach as you'd incur the overhead of version matching your custom program over ACT! upgrades and modifying your code and redeploying to multiple locations at each object change (hotfixes, service packs etc...).
Consider taking the approach where you build a web service on a machine with ACT! installed for the entities you want to manipulate. Your .Net winforms client can then bind to the web service and is abstracted from deltas that happen on the application side - any changes due to ACT! upgrades take place on your web server only and no redployments need be made. Conceptually this is similar to what technologies like Adobe Air provides - a local, rich user experience bound to data manipulation classes that happen to be web services behind the scenes.
As an FYI -we are using WCF contracts and publishing very basic web services for an upcoming feature in ACT! 2011 so when that is available I'll be able to provide some example of reusing those web services in ACT! 2011.