Hi Josh,
I think I have the answers or at least some of them.
1) if the program is "in" an object, that means that it is a method. Therefore, you should be able to extract certain information about the business object from the RPE (runtime program environment). Specifically, there are RPE variables that you either get by:
set sType [mql get env TYPE]
set sName [mql get env NAME]
set sRev [mql get env REVISION]
Matrix also provides "macros" to the TCL environment that sort of do the above for you, such as:
set sType ${TYPE}
set sName ${NAME}
set sRev ${REVISION}
either way works. You can look in the matrix online docs for the macros appendix and get the whole thing, including what macros (RPE vars) are available for every event that occurs in Matrix to businessobjects, relationships, policy state promote/demote events, and attribute modification events.
One final note: a method program object should indicate that it needs a business object in the program object defenition in the Business tool. This will ensure that the correct macros are there.
2) executing from MQL. You have to fenagle a method to run it as a 'raw' TCL utility program from MQL. First, the above macros WILL NOT BE AVAILABLE. Therefore, you must pass the type/name/rev info as arguments to the program. So to get:
<MQL> exec prog myProg.tcl Drawing 1234 A;
to pick up the args, when the main part of your program runs, (not in a PROC) you have to retrieve the args from the RPE either by:
set sType [mql get env 1]
or
set sType ${1}
etc.
You will have to turn off "requires businessobject" in the prog object def in the Business tool to make this work however, so you will have to change it again when testing as an actual method in the eMatrix tool so you can use the RPE vars TYPE/NAME/REVISION, etc.
To make your program more flexible, have it look initially for the RPE vars, and if they are not there, then look for the arguments. If neither is there, throw an error.
Also, check out the special TCL "args" argument. An alternative to using positional arguments in PROCs is to just pass "args", then once in the PROC, foreach the $args (a list). When I do this I use name=value pairs, and provide defaults for all missing and optional arguments that the PROC recieves. So my proc call might look like:
set x [myProc "sRev=A" "sType=Drawing" "sName=300600"]
and my proc looks like:
proc myProc {args} {
foreach arg $args {
switch $arg ... (and match the args, supply defaults for missing optional args)
}
}
3) context. Sounds like you have not done:
set context user me password mypassword;
verb on;
or that somehow you are loosing context (ie: the program is trying to set context inside the code to a non existant user or with a bad password)
One trick you can use in your TCL program is to "push" and "pop" context. This approach is most often used when a trigger or other program must have access rights greater than that of your user. So you create a 'secret' user in the system (say with admin rights), push context to the admin user, do your thing, and then pop context to get back to the original user. BEWARE - this means that an administrative user's name and password are in the source code of your program. HOWEVER, as long as you are careful with admin privaledges, no unauthorized person should have the Business tool nor have access to view program code. So, be careful of who you dole our privaledges to.
4) context as argument. Shouldn't need to do it, but checkout the above (also not the RPE var USER). HOWEVER, you need to see what is going on inside that script and why you are loosing context. I HIGHLY recommend that you get the TCLPro debugger from:
and learn how to use it. This is a powerful tool and you really need it.
5) Object lock & checkin. You could do this as a business object method OR you could just create a CHECKIN trigger. Look in the matrix docs on triggers. There is are 3 kinds of triggers for each supported event:
CHECK - pre-event: make sure you want to let the event happen, or "hard" block if you don't
OVERRIDE - pre-event: make sure you want to let the event happen, or "soft" block if you don't & replace the event with your own event (this is a little tricky to figure out at first but is really powerful).
ACTION - post-event: after the event has happened (either a pass on the CHECK or a replace on the OVERRIDE) do you want to do something else to the object or related objects (such as connect relationships, etc.)
In your situation you may want to:
CHECKIN event - CHECK: is the busobj in the correct state? IF yes, then pass, IF no, then fail and notify user
CHECKIN event - ACTION: after the files are checked into the busobj, LOCK the busobj.
Hope this helps!
Regards,
John Lopez
mailto:consulting4matrix@hotmail.com
330.947.3800
P.O. Box 290
Deerfield, Ohio 44411 John Lopez
Enterprise PDM & Integration Consulting
Development for MatrixOne PDM Systems
johnlopez2000@hotmail.com
Red-eyed, mumbling mammal capable of conversing with inanimate objects.