Calling the APIs from VBA
Moderator: SourceGear
Calling the APIs from VBA
Has anyone successfully set up a mechanism for calling the APIs from VBA like you can with the VSS APIs? We will need to do so eventually for your project.
Re: Calling the APIs from VBA
We have a specific forum just for the API and there is already some discussion in regards to this. You may find the following link useful:
viewtopic.php?p=79025&hilit=vba#p79025
Tonya
viewtopic.php?p=79025&hilit=vba#p79025
Tonya
Re: Calling the APIs from VBA
You should clarify which APIs you want to call.Has anyone successfully set up a mechanism for calling the APIs from VBA like you can with the VSS APIs?
- The MSSCCI API, which is implemented in a native C(++) DLL. - Will be extremely difficult with VBA because this API uses the cdecl calling convention, while VBA supports only stdcall with the built-in Declare syntax.
- The Web APIs - Technically easy to implement with web requests (I assume!), but as far as I know, undocumented and not supported for custom extensions.
- The client libraries - A supported/recommend way to built custom functionality. However, I don't think these libraries are ComVisible. So, it would be necessary to build a COM Wrapper around those in e .Net language.
- The command line - Easy to implement but has limited functionality in terms of integration into a complex process.
Re: Calling the APIs from VBA
Hi Philipp,
My thought was to call the client libraries but as you noted I don't think they are Com visible which as you note would require writing a Com wrapper for each function which is not particularly easy and not something I have done before. My hope here is that someone else would have done so previously and I could leverage off of them.
Calling the Web APIs and the command line APIs are basically the same thing (correct me if I am wrong) and present the same challenges. I have successfully duplicated the basic functionality of VSSDatabase and VSSItem using the command line method and it does work. However each command effectively logs into Vault separately and thus carries that overhead. Normally this is not an issue but can greatly slow things down if you are iterating through the files in a folder issuing a command one by one (Get from a project or Add to a project for example). There are some ways I can speed this up (getting a project as one command, using wildcards or getting the entire project and then later removing the excluded files) but there will most likely be situations where we need to call Add in this manner and would prefer to not have the additional overhead which can slow the total time to iterate through the loop down by a factor of as much as 10 times.
Our main automations are to get the files from our Production project into the build directory for automated builds, to promote files from our Development project to our Test project when they are approved for testing and to promote files from our Test environment to our Production environment when a production release is done. Sometimes this can involve every file in a project and our projects, of which we have a couple of dozen, can come close to 800 files each though 100-600 is more normal.
My thought was to call the client libraries but as you noted I don't think they are Com visible which as you note would require writing a Com wrapper for each function which is not particularly easy and not something I have done before. My hope here is that someone else would have done so previously and I could leverage off of them.
Calling the Web APIs and the command line APIs are basically the same thing (correct me if I am wrong) and present the same challenges. I have successfully duplicated the basic functionality of VSSDatabase and VSSItem using the command line method and it does work. However each command effectively logs into Vault separately and thus carries that overhead. Normally this is not an issue but can greatly slow things down if you are iterating through the files in a folder issuing a command one by one (Get from a project or Add to a project for example). There are some ways I can speed this up (getting a project as one command, using wildcards or getting the entire project and then later removing the excluded files) but there will most likely be situations where we need to call Add in this manner and would prefer to not have the additional overhead which can slow the total time to iterate through the loop down by a factor of as much as 10 times.
Our main automations are to get the files from our Production project into the build directory for automated builds, to promote files from our Development project to our Test project when they are approved for testing and to promote files from our Test environment to our Production environment when a production release is done. Sometimes this can involve every file in a project and our projects, of which we have a couple of dozen, can come close to 800 files each though 100-600 is more normal.
Re: Calling the APIs from VBA
For building a project I would always get all files of the repository folder (and label). I don't think this can be done any faster than using GET or GETLABEL on the command line.
If you have to process a number of individual files, I recommend you investigate the BATCH command. - This should use a single open connection to the server for the whole batch of operations and thus should circumvent the overhead of creating a new connection for each operation.
@Tonya: I think, the documentation of the BATCH command should be expanded. Without an example it is hard to understand how it is supposed to work. Also, it is unclear to me whether a CHECKIN command in BATCH mode will be automatically committed or whether an additional COMMIT/CHECKIN command is required.
If you have to process a number of individual files, I recommend you investigate the BATCH command. - This should use a single open connection to the server for the whole batch of operations and thus should circumvent the overhead of creating a new connection for each operation.
@Tonya: I think, the documentation of the BATCH command should be expanded. Without an example it is hard to understand how it is supposed to work. Also, it is unclear to me whether a CHECKIN command in BATCH mode will be automatically committed or whether an additional COMMIT/CHECKIN command is required.
Re: Calling the APIs from VBA
Hello,
Thank you for your input in regards to adding more specifics to the CLC help documentation. I will make sure to get this logged in our system as a consideration for improvements. The Batch CLC command is going to checkin files as the normal checkin command would function. CHECKIN will commit the items in the pending changeset list specified by repositorypath(s).
Tonya
Thank you for your input in regards to adding more specifics to the CLC help documentation. I will make sure to get this logged in our system as a consideration for improvements. The Batch CLC command is going to checkin files as the normal checkin command would function. CHECKIN will commit the items in the pending changeset list specified by repositorypath(s).
Tonya
Re: Calling the APIs from VBA
Phillip,PhilS wrote: ↑Fri Nov 01, 2024 1:49 pmFor building a project I would always get all files of the repository folder (and label). I don't think this can be done any faster than using GET or GETLABEL on the command line.
If you have to process a number of individual files, I recommend you investigate the BATCH command. - This should use a single open connection to the server for the whole batch of operations and thus should circumvent the overhead of creating a new connection for each operation.
We ended up doing both of these things, using the get command on the entire project and then batching as many of the other commands to get the version, checkout and other information. While we were not able to get down to the 13 seconds it takes using VSS to accomplish the same task we did get down to 28 seconds which maybe could be compressed further if we didn't separate the commands into three batches to make error handling easier. I should note that we have a lot more work to do as I only have concentrated on the build side of things in our automated system, it also automatically promotes files from the development project to the test project to the release project and adds labels and that part has not yet been tackled.