The tool seems quite simple to master and I think it can be quite useful.
On the other hand, I don't have too many ideas of what it can really be used for on a real EPDM database/workflow (for now the nicest example I found is here: http://www.caddirt.com/blog/2011/4/4/epdm-dispatch-jumpin.html it's a data check on a step of the workflow to inform the user and offer to fill in the data).
I hope that some in the community have had fun with the tool and give ideas to others.
Max your idea interests me a lot since we would like to be able to regularly back up our SW database outside of EPDM (we're afraid of the full crash ;-) ). Could you share your .acn?
We have also planned tasks for the automatic printing of the pdf when the plan is validated.
The dispatch would rather be to have a total backup of SW files outside of EPDM (so a SW file database that can be totally exploited independently of EPDM). Basically, it would be a copy of the local cache with all the files up to date in the latest version.
I tested your dispatch adding the E: quite a nice function. I think I'm going to make a derivative of it.
On the other hand, I didn't understand the difference between the 2 dispacth valid/invalid module state (maybe it's because I don't have the same variables as you: so the variables don't appear in my house)
I'm importing my 80GB into EPDM to test. Selecting all the parts files via the search tool to do a check in seems difficult (too many files, too long to have the right click menu....). Could a dispatch automatically check me for all files of a certain type? Seeing your file adding the E it doesn't look very complicated. I'm going to start programming....
During the implementation phase, for example, when it comes to state changes, these manoeuvres can take a very long time from a CAD station. We had carried out a lot of operations from the server directly, we saved ourselves the slowness due to the passage of information from the server to the PC and from the PC to the server. It doesn't seem like it at all, but when you were processing thousands of files, it considerably reduced the response and processing time.
Hello Benoit and thank you for the comment that may help some.
My import is already done on the server with local view on the same archive server. just to put my 80GB in the local view via a copy/paste (without checkin) I already had for about ten hours.
Now I'm trying to check my parts only (then I'll do my assemblies and finally my MEPs).
I did a bit of dispatch but it's not very conclusive for the moment (and I made the mistake of running it on my entire database before testing it on a file or small folder -> my server is having a hard time...).
I too participate in the edifice for the next "lucky ones" to try the adventure of EPDM admin.
In attachment 3 dispatch allowing to archive files according to the type of file extension.
There is one for parts (validated and approved), one for assemblies and one for drawings (not yet tested for these two but there is no reason why they should not work).
Archiving is only done if:
1) the extension is the one chosen
2) the file is not yet in a workflow state (I use it to do my first archiving and it was easier for me to program than to check if the file was already archived or not)
Don't hesitate to participate even after the post is closed because examples of dispatches are not common
I'll leave it to someone else to do the tutorial because I already have enough work as it is to debug my database. The link I put in my topic already explains a lot of things (English only though).
Lynkoa is already well referenced by google: an admin doing a good search should find it easily ;-)
For your question about the transfer rate when copying my existing SW database to the local view of the server, I was connected remotely to the server. So the copy was done from server to server. On the other hand, the simple fact of copying files into the local view already generates EPDM transactions. In practice EPDM directly creates a copy of the file in the safe, it also writes information in the sql database (the fact that the files are extracted on the server by the admin, dates....). So all this takes time/resources.
On the other hand, I have absolutely no idea if the 2MB/s you get is normal or not (I don't work at Axemble so I don't have any other point of reference).
Currently, I am proceeding with the first archiving of the documents using the dispatch that I have attached. It's even slower (about 40 files archived per minute). But there are many more SQL transactions (entry of file data, configuration data, versions when the file is passed through the import workflow, etc.).
In addition, my dispatch regularly crashes when there is an error / warning message on the archive operation (missing file (like .cwr from cosmosworks), duplicate...), A pop up appears and as long as you don't click on OK the dispatch is blocked. So my dispatch doesn't seem to be the right solution to do this first archiving of my files.
We are derived from the initial post but does anyone have a solution to do this first archiving "quickly" (or at least without blocking: if I manage to archive 99% of my files quickly and there are only 1% of problem files left that are not archived it's not too bad)?