Setting Up an EPDM Dispatch Script to Rename SolidWorks Files

Setting Up an EPDM Dispatch Script to Rename SolidWorks Files

Table of Contents


Dispatch

Dispatch is a very powerful EPDM tool which can be used for a variety of file
specific operations. A very common need for the Vault would be an easy way to
rename large amounts of SOLIDWORKS files based on certain data card values,
and/or user inputs. This can be very easily accomplished with the use of a
dispatch script. In the following example, I will explain the logic behind
creating a working script to rename SOLIDWORKS files based off of a data card
value. It is important to consider the manner in which you order your
operations in the script. For each run of the script, it will execute each
command from top to bottom. It is also very important to note that the script
that is illustrated here will only work for SOLIDWORKS files. It is possible to modify this script for it to work on all file types. This
will be explained later in the article. The following pictures illustrate a
finished rename Dispatch script:

Edit action

Set variables

(1) Here we have the method of activation. I have specifically assigned this
script to run on “Menu command.” This means that if I right click on a file or
set of selected files, one of my menu options will always be to “Rename
SOLIDWORKS Files.” The upside to this is that it will allow you to rename
files whenever needed, as opposed to during a state transition, during a
checkout/in operation, or file add, which are operations that have
prerequisite functions that need to be completed in order to trigger the
dispatch. The downside, however, is that it will be available to everyone in
the Vault. If you wish this type of operation to be completed by select
individuals with certain permissions, I would suggest using the “During State
Transition” condition, where you can assign “Permit” privileges to that, and
in effect, to the dispatch script.

(2) Here we start out with a simple message prompt to the user which has a
possibility of the user either pressing YES or NO. We are asking the user,
only once, if all files are checked in prior to running this script. Based on
the user’s response, the value is saved in the runtime variable
“d_runtimeansweryesno”, shown in figure (10).

(3) This portion relates to the function detailed above in that we are
implementing a conditional action based on the option chosen in figure (2).
The IF statement compares the value saved into “d_runtimeansweryesno” and then
compares it to a value we defined manually in the IF statement dialog. In this
case, I manually typed “YES” into the IF statement dialog box. If the user
selects “YES”, it will be saved into the runtime variable, compared, and then
sent to the label “YES” and continue on with the bottom portion of the script,
figures (4) – (6). If the user selects “NO”, then the script will prompt the
message “Please check in all files before running this dispatch.”, and then
proceed to a second “IF condition which always jumps to the label “END”,
terminating the script.

(4) From here we start the portion of the script which allows for multiple
files. As mentioned earlier, a Dispatch script has the potential to run for
multiple files or for one file. If a user selects multiple files, a “For all
documents” command is needed to tell the script to rerun the operation for
ever file in the selection. It was placed in its current position specifically
due to the fact that if we placed it at the very beginning of the script,
above figure (2), then it would run the message prompts for every file that it
selected, theoretically.

(5) Here is the main rename operation. We are defining the file in question
with %PathToSelectedFile% as this will ensure the rename operation runs on
only the file we selected. We are renaming it, in this case, with another
dispatch variable “d_newfilename” which is shown in figure (9).

(6) Here we have the block end. Very simply, if you have a “For all
documents”, you need an “End for all documents” to finish the loop.

(7) Here we have the dispatch variable “d_extension”. Because a rename
operation with dispatch takes into account the entire filename including the
extension, we need to extract the extension of the original file name, in
order to use it after the file is renamed with our intended value. Because
SOLIDWORKS files always have a 6 character extension, we are saving the
rightmost 7 characters, which includes the period separator. The value should
now be saved into the “d_extension” variable.

(8) Here we have the dispatch variable “d_number” which is mapped to the value
of a data card variable value for the specific configuration “@”.

(9) Here we complete the operation of combining the saved Number variable
value with whatever the file extension is, giving us a valid SOLIDWORKS file.

(10) Here is the runtime variable that was referenced in the first operation,
Figure(1)

 

As mentioned previously, this script as it is written will only work for SOLIDWORKS files. This is due to the simplicity in which the script was written, and the
script can be modified to work for all file types by adding more complex logic
to it. The level of complexity, however, is determined by what value you want
applied to the filename, and how you want it applied.

Regardless, you would need to first determine a better way to find the
extension of your file. The method listed in the pictures above shows logic of
how to get the rightmost 7 characters of a file, but if this script was run on
a “.docx” file, a “.dwg” file, or any other file that does not have 6
characters in the extension, it would produce improper results. In order to
allow for the possibility of reading in multiple extensions, you would need to
let “d_extension” equal the following value:

Mid(%NameOfSelectedFile%,Find(%NameOfSelectedFile%, .),7)


What this essentially does is locate the position of
the “.” in the filename, and then select that character plus any other
characters to the right of it. The Find(%NameOfSelectedFile%, .) ends up reporting a numerical value of the position of the “.” The rest of
the command stipulates that any characters to the right of the specific
position, including the character position specified will be saved. Notice how
we still leave the “7” in the command. This is because it will look at up to 7
characters to save, if they exist. Since we know the largest extension in a
vault is the SOLIDWORKS file, with 6 characters, we know it will pick up
those. As far as “.docx” or “.dwg” files or anything containing less than 6
characters, it will simply ignore any empty characters after the extension. As
a result, you could theoretically replace that “7” with “10000”, and it would
still return the same result.
The next step would be to allow cases for files that have different data
cards. SOLIDWORKS files have a default “@” configuration, “DWG” files have a
“Model” configuration, Office Documents have no configuration, etc… Due to
the fact that a dispatch variable value requires a configuration
specified(or an empty configuration value if there are no configurations for
the file) you will need to create multiple dispatch variable for each
potential case, and then add “IF” statements to the existing script, allowing
the script to proceed appropriately for each specific case. Obviously, this
could add considerable length to the existing script, so it would be important
to test thoroughly once you feel the script has been completed.

 

Miles Hoffman

Miles Hoffman

Miles Hoffman is a PDM SPECIALIST with CSWP-D, CSWS-D16, CSWP certifications, and is based out of the Mountain View, CA office.
0 0 votes
Article Rating
Subscribe
Notify of
guest

7 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
David
David
2 years ago

I finally managed to rename files! Thank you!

Tyson
Tyson
2 years ago

Hi Miles, I tried using your script word for word and have checked it multiple times. The only difference is our part number variable is called PartNo, so I linked to that variable instead. The script works fine through the Yes/No prompts but the part number comes out blank in the end. Could the problem be that our PartNo variable is created from a concatenated input formula? IE CommodityCode-SerialNumber. Thanks for any help.

Tyson

Tyson
Tyson
2 years ago

Figured this out later that day. Just started fresh and simple and it ended up working. Thanks for the article.

Stephen Mullen
Stephen Mullen
2 years ago

I want my Dispatch script to compare the Data Card Document Number to the Filename to confirm they match. Any help appreciated

Chris Nell
Chris Nell
2 years ago

Hi,
I did a similar scripte but I think that it is a lost of time to ask the user to manually check that the file is check-in! It should be a solution to do this verification on a parameter but I can’t find out which variable gives me this information. Any idea? Is it possible to access the “check out by” variable from the dispatch?

Miles Hoffman
Miles Hoffman
2 years ago

Hi Stephen,

I am very sorry for the late reply, but what I would do in this case, is create a dispatch variable which pulls in the name of the file without the extension, and then create another which pulls in the value of the Document Number variable. You could then use a “Jump” command to compare the two. If they match, the script can jump to an “End” label and restart for the next document. If they don’t match, you can have it “Jump” to a line in the script which renames the file based on the number, then after have it jump to another “End” label so that the script restarts again for the next file.

Miles Hoffman
Miles Hoffman
2 years ago

Hi Chris, Sorry for the late reply, and thank you for your comment. I agree that minimizing wasted time is a goal with every scripted project. In this case however, there is no native parameter in dispatch to check whether a file is checked in or out. The only thing you can do is evaluate a value on a data card using a jump command. Interestingly enough as a result, in order to fulfill that requirement, you would actually have to create a second dispatch script to write a variable value to the data card every time a file is checked out, and erase it every time the file is checked in, but that would put a large and unnecessary load on the database since the action would need to be done for all files, and check in/out actions occur all the time. As a result, the best method would be to leave the script as is, or simple remove the warning if it becomes annoying. It is mainly for users who are less experienced with the vault and the use of a renaming script anyway, and is a safeguard to ensure files are not renamed accidentally. As experience grows in the vault, such a warning is not needed. Thanks again for commenting!