UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Docusign Or Similiar, Anyone Navigated Those Waters?, Access 2010    
 
   
jimbofoxman
post Apr 9 2020, 01:33 PM
Post#1



Posts: 406
Joined: 4-April 08



Has anyone navigated the Docusign or similar type products yet, with integrating them in with your Access database? We have a database we use for quoting and tracking all our installation projects and more and more stuff is being sent vial email to customers. With this whole COVID stuff, it has been asked to look into some sort of docusign type setup. In looking so far this morning their is not a lot of information about Access and Docusign being used together. Their API stuff all refers to C#, Java, Node.js, PHP, Python, and Ruby. As well, I am really not familiar with API stuff at all.

If anyone has done this, can you give any recommendations on where to start from, especially for someone who hasn't done much programming beyond MS Access?

Thanks!
Go to the top of the page
 
AlbertKallal
post Apr 9 2020, 08:01 PM
Post#2


UtterAccess VIP
Posts: 3,053
Joined: 12-April 07
From: Edmonton, Alberta Canada


Yes, I have done this.

However, all of their examples, code and library stuff was in .net.

So, cobbled together the code in .net (vb.net), got some base test code working with EchoSign.

And then I simply created a .net class as a "com" object. That's a fancy way of saying I exposed the .net code to be used from Access.

So, now in Access I could go:

CODE
dim EchoSign       as new EchoSign.Sign
dim strFile    as string
dim strDoDisplay  as string
strReceipent as string

' set all of above to some values
strReceipent = "kallal@msn.com"
et.
then

dim strMyResult as string

strMyResult = EchoSign.SendForSighning(strFile, strDocDisplay, strRecipient, DaysToSignDeadline, _
                                                        Echosign.RecipientRole, UseWebIdent, strMessage)


So above is how the VBA part looks.
And all of the bits and parts that "interact" with their web site and web service was done in .net.

You then like any other external object (Excel, outlook, or YOUR .net code), can create a object of the .net code you write and use it as per above.

The above of course assumes that you have half decent .net skills. I don't suggest attempting to write this web interface code in VBA, as it would be rather complex,, and their development kits all are built around with .net samples and code in mind.

However, this tends to result in a nice setup. You build the interface and routines you need, and once done, then your are back to plane jane access stuff.

So, if you spit out a nice invoice or purchase order in Access (say a report to PDF), then you can send the PDF up to the web site, and the correct party will be notified. They go to the web site - see + view the invoice, and then they approve it (in effect digital sign/approve the invoice or purchase order).

Now, in Access, you can call a routine with a passed list of invoices, and the system will spit back which ones have been approved, and which ones are pending, or not approved. So, you update the status in Access. Say on a nice continues form or whatever.

It all works quite well. As noted, I do recommend that you have decent .net skills. And on top of the .net skills, you need .net experience in how to create a "com" class for use from Access (or any office/windows application). It not all that hard, but it comes down to knowing how to wire all this up.

I am constant writing "interfaces" in .net.

So, for example, we needed to send invoices from Access to QuickBooks. (and then later on Sage 50). and then later on Sage 300.

So, in the above 3 cases, I used the .net "SDK" kits from QuickBooks and Sage (formally Simply accounting) to build the invoice interface, and then in Access simple created instances of the .net object and was able to send/push invoices from Access to QuickBooks.

I think QuickBooks still supports CreateObject() from Access VBA, but Sage does not (but there interface kit to sage 50 is available in .net).

So, once again, a good number of their interface kits and samples are all written around .net. So, it was FAR easier to build the interface in .net - and expose it to Access.

So, tops in the .net skills and something I learned from near day 1 in .net and Visual Studio?

Well, being primarily a Access developer? Then it was how to create COM objects in .net for exposure to Access.

I now have done this so often, that it is a regular occurrence to call + use .net code from Access.

So, to use EchoSign, you likely want to build the interface in .net - since that's what their SDK kits and samples are built around.
Once done, it was quite easy to expose the .net parts to Access for use from VBA.

So, the above is where I would start. (Visual Studio - vb.net). I used vb.net since it so similar to VBA. But, these days, a lot of sample code is in c#.

Another possible is to have someone develop the .net part for you, and once done, then most if not all of the remaining coding will occur in Access.

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada

Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    25th May 2020 - 02:58 AM