Tuesday, November 11, 2008

Intralink SQL: User and Group Folder Authorizations

Intralink stores folder authorizations in four Oracle tables. Two for user authorizations (PDM_USERFOLAUTH and PDM_USERFOLRLAUTH) and two for group authorizations (PDM_USERGRFOLAUTH and PDM_USERGRFOLRLAUTH).

The PDM_USERFOLAUTH and PDM_USERGRFOLAUTH tables contain folder role authorizations. The PDM_USERFOLRLAUTH and PDM_USERGRFOLRLAUTH tables contain folder authorizations by release level.


Query for user folder role authorizations:

-- user folder auth
--
set linesize 135
col folpath format a60
col userexpname format a12
col rolename format a15
--
select
FOLPATH,
USEREXPNAME,
ROLENAME
from
pdm.PDM_USERFOLAUTH ufa,
pdm.PDM_ROLE role,
pdm.PDM_FOLDER fol,
pdm.PDM_USER usr
where
role.ROLEID=ufa.ROLEID and
ufa.FOLID=fol.FOLID and
ufa.USERID=usr.USERID
;
 


Query for user folder/releaselevel role authorizations:

-- user folder/releaselevel auth
--
set linesize 135
col folpath format a60
col userexpname format a12
col rlname format a15
col rolename format a15
--
select
FOLPATH,
USEREXPNAME,
RLNAME,
ROLENAME
from
pdm.PDM_USERFOLRLAUTH ufrla,
pdm.PDM_RELEASELEVEL rl,
pdm.PDM_ROLE role,
pdm.PDM_FOLDER fol,
pdm.PDM_USER usr
where
role.ROLEID=ufrla.ROLEID and
ufrla.RLID=rl.RLID and
ufrla.FOLID=fol.FOLID and
ufrla.USERID=usr.USERID
;
 


Query for group folder role authorizations:

-- group folder auth
--
set linesize 135
col folpath format a60
col rolename format a15
col grexpname format a25
--
select
FOLPATH,
GREXPNAME
ROLENAME,
from
pdm.PDM_USERGRFOLAUTH gfa,
pdm.PDM_ROLE role,
pdm.PDM_FOLDER fol,
pdm.PDM_USERGROUP grp
where
role.ROLEID=gfa.ROLEID and
gfa.FOLID=fol.FOLID and
gfa.GRID=grp.GRID
;
 


Query for group folder/releaselevel role authorizations:

-- group folder/releaselevel auth
--
set linesize 135
col folpath format a60
col grexpname format a25
col rlname format a15
col rolename format a15
--
select
FOLPATH,
GREXPNAME,
RLNAME,
ROLENAME
from
pdm.PDM_USERGRFOLRLAUTH gfrla,
pdm.PDM_RELEASELEVEL rl,
pdm.PDM_ROLE role,
pdm.PDM_FOLDER fol,
pdm.PDM_USERGROUP grp
where
role.ROLEID=gfrla.ROLEID and
gfrla.RLID=rl.RLID and
gfrla.FOLID=fol.FOLID and
gfrla.GRID=grp.GRID
;
 


Putting it all together

To streamline these queries, unions can be used to combine the output into one report. In the following example, user and group names are reported under the 'ID' column. The final where clause can be used to filter for a specific user or group. Leave it out to report authorizations for everyone.

The report is also enhanced in that the order of the release levels in the output matches the output one would see in the folder authorization window in Intralink Admin.

The syntax is somewhat inefficient because it is setup to allow outer joins based on folders (see end of article). However, even for very large numbers of folders, user, and groups, the combined query is still pretty fast.


-- user & group auth
--
set linesize 200
column folpath format a70
column rolename format a20
column rlname format a15
column id format a25
--
select FOLPATH,id,rlname,rolename,rlseqnum
from
(
select
folpath,
(select userexpname from pdm.pdm_user where userid=ufa.userid) as id,
'' as rlname,
to_number('') as rlseqnum,
(select rolename from pdm.pdm_role where roleid=ufa.roleid) as rolename
from
pdm.pdm_userfolauth ufa,
pdm.pdm_folder fol
where
ufa.folid=fol.folid
UNION
select
FOLPATH,
(select userexpname from pdm.pdm_user where userid=ufrla.userid) as id,
(select rlname from pdm.pdm_releaselevel where rlid=ufrla.rlid) as rlname,
(select rlseqnum from pdm.pdm_releaselevel where rlid=ufrla.rlid) as rlseqnum,
(select rolename from pdm.pdm_role where roleid=ufrla.roleid) as rolename
from
pdm.PDM_USERFOLRLAUTH ufrla,
pdm.PDM_FOLDER fol
where
ufrla.FOLID=fol.FOLID
UNION
select
folpath,
(select grexpname from pdm.pdm_usergroup where grid=ugfa.grid) as id,
'' as rlname,
to_number('') as rlseqnum,
(select rolename from pdm.pdm_role where roleid=ugfa.roleid) as rolename
from
pdm.pdm_usergrfolauth ugfa,
pdm.pdm_folder fol
where
ugfa.folid=fol.folid
UNION
select
FOLPATH,
(select grexpname from pdm.pdm_usergroup where grid=gfrla.grid) as id,
(select rlname from pdm.pdm_releaselevel where rlid=gfrla.rlid) as rlname,
(select rlseqnum from pdm.pdm_releaselevel where rlid=gfrla.rlid) as rlseqnum,
(select rolename from pdm.pdm_role where roleid=gfrla.roleid) as rolename
from
pdm.PDM_USERGRFOLRLAUTH gfrla,
pdm.PDM_FOLDER fol
where
gfrla.FOLID=fol.FOLID
)
where
id like '%smith%'
order by folpath,id,rlseqnum
;
 


Outer Joins for More Information

To show all folders, regardless of whether they contain any authorization settings, add the following outer join syntax to the above:
      ...folid(+)=fol.folid
 

There will be some minor duplications, but it does give a good sense of where the authorizations are set in your folder hierarchy.

Tuesday, August 19, 2008

Pro/ENGINEER: Anatomy of a Trail File, Part 3

Read Part 2

In my experience, there are three main uses for trail files: Recovery, Benchmarking, and Templating. Generally speaking this series of articles is about templating trail files. Templating is the modification of trail files to perform actions that are not specific to a particular model.

In more complex trail files, selection of items eventually becomes a necessity. Doing this in a repeatable way can become very challenging, especially if working with different models or models that are changing often.

Selections of models, features, annotations, and notes can be accomplished in various ways, but selections of geometry items such as surfaces and edges are very difficult in such a manner that it works for different models. Trail file selections using the graphics window are almost never transferable for use with other models.

Model Tree

When you click on an item in the model tree, you'll see, for example, "node4" or "node31" appear. Here is an example of a trail file entry caused by selecting 'Note_1'.

~ Select `main_dlg_cur` `PHTLeft.AssyTree` \
1 `node6`
!Note_1
 
These node numbers are assigned by Pro/ENGINEER on a first come, first served basis. When the model is first opened the node numbers are assigned in a bottom first, upwardly increasing sequence, based on what is displayed at that time.

For example, if the model tree of a part is shown with features and annotations when the model is opened, the following table reflects the node number assignments. The top level item (the part itself) is node 0 (zero), then working up from the bottom the node numbers increase. As you can see, even the 'Insert Here' pointer has a node number.

 Item        Node #
ABC.PRT 0
Note_0 8
Note_1 7
Note_2 6
Feat1 5
Feat2 4
Feat3 3
Feat4 2
Insert Here 1
 
The tricky part comes when new nodes are shown either through expansion of existing nodes (i.e. to show features of a component) or modification of the model tree filters. Regardless of where in the model tree they appear, the new nodes are given new node numbers based on the previous largest value.

As an example, if your model tree initially shows nothing, then annotations are added, then features are added, you might get a result like this:

 Item        Node #
ABC.PRT 0
Note_0 3
Note_1 2
Note_2 1
Feat1 8
Feat2 7
Feat3 6
Feat4 5
Insert Here 4
 
The node numbers for a complex assembly might even appear to be randomly assigned. Disappointingly, use of 'Expand All' doesn't produce very orderly node number assignments.

Beyond the top level nodes, use of the model tree can be very complicated. It is definitely something that can be done, but requires some preprocessing to generate a trail file programmatically before it is run. Most likely, trail files making more than trivial use of the Model Tree will not be usable for other models.


Search Tool

Another approach to selections with trail files is the "Search" tool (i.e. Edit -> Find). The Search tool works very well when selecting items with a trail file. Selections of specific models, features, or numerous other entities can be accomplished easily.

The downside to this approach is that you lose some control over where in an assembly hierarchy objects can be located. An option exists to search only in the top level, but an 'All Levels' search will return results from any level.

Another difficulty is that multiple results will be obtained when searching for common objects, such as hardware parts, shared subassemblies, and models with standard features, etc. There is a mechanism to select specific items, but this requires a great deal of information that has to be provided ahead of time.


Defaults

Another thing to keep in mind is that the last option you use in the Search Tool may be the default option when the Search Tool is used a second time. A recommendation is always to set explicitly every option (even if it is the default) every time the Search Tool is used with a trail file. This will produce more robust trail files.

It may be extra work to click on other options that you don't want in order to record the selection that you do want, however it's worth the effort. Extra baggage code in the trail file can usually be removed, if that is desirable.


Example

A typical scenario is the need to select an item such as a component, a feature, or a note using its name. Here is an example of using the Search tool to search an assembly for a subassembly called 'A.ASM'. I have added comments to indicate the major sections.

!! Start the Search tool
!!
~ Select `main_dlg_cur` `MenuBar1` \
1 `Edit`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `Edit.Find`
!!
!! Select entity type to be searched for
!!
~ Open `selspecdlg0` `SelOptionRadio`
~ Close `selspecdlg0` `SelOptionRadio`
~ Select `selspecdlg0` `SelOptionRadio` \
1 `Prt_or_Asm`
!!
!! Limit search to top level
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
0
!!
!! Enter name
!!
~ Update `selspecdlg0` `ExtRulesLayout.ExtBasicNameLayout.BasicNameList` \
`A.ASM`
!!
!! Perform search by clicking 'Find Now' button
!!
~ Activate `selspecdlg0` `EvaluateBtn`
!!
!! Selecting item(s) in results
!!
~ Select `selspecdlg0` `ResultList` \
1 `-1:69:[39]`
!!
!! Hit 'Close' in Search dialog (even though it says 'CancelButton')
!!
~ Activate `selspecdlg0` `CancelButton`
 
If you follow along in your trail file while performing the search, you can see that each action produces a certain output, which is mostly self explanatory. What is not so obvious is the syntax of the output when items are selected in the search results.


Selections

The syntax used for selection of components differs from the selection of other types of entities, but it is similar. The `-1:69:[39]` specifier is a colon separated list of three fields: ID, Type, Component Path.

The first field is an item ID field (i.e. feature id, note id, etc), except for components where it always shows -1. The second field is a numeric code corresponding to the type of entity in the search, whether that be 'Feature', 'Annotation', 'Component', etc. The third field specifies a "Component Path" which is a list of component feature IDs from a top level to a subassembly or component. The "[39]" indicates that the selected component is feature ID 39 in the top level assembly.

A selected item generating this syntax `2:147:[40][40][41][61]`, is a note (or some other annotation) with id 2 and found through the component id sequence of 40 (level 1 component id), 40 (level 2 component id), 41 (level 3 component id), 61 (level 4 component id).


Select All

The "Select All" action (Ctrl-A) can be used at any time and generates the following trail code. Even if a selection of an item is required for an interactive user prior to using "Select All", this can be used without it in a trail file.

~ Select `selspecdlg0` `ResultList` \
-1
 

Depth

The depth of the search is controlled by the "Include submodels" option in the Search Tool dialog. Checking or unchecking this option adds one of the following code sequences to the trail file.

!! Limit search to top level ('Include submodels' is not checked)
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
0
 

!! Search all levels ('Include submodels' is checked)
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
1
 

Closing The Dialog

As you can see from my comment, hitting Close in the dialog adds a curiously named "CancelButton" entry. Just remember if you're editing the trail file, that this means "Close".

!! Hit 'Close' in Search dialog (even though it says 'CancelButton')
!!
~ Activate `selspecdlg0` `CancelButton`
 

Types

One of the first things typically done when using the Search Tool is the choice of entity type. If you're familiar with the tool, you know that there is a very wide range of type options to choose from.

Type selection generates code such as this:

~ Open `selspecdlg0` `SelOptionRadio`
~ Close `selspecdlg0` `SelOptionRadio`
~ Select `selspecdlg0` `SelOptionRadio` \
1 `TYPENAME`
 
Some examples of `TYPENAME` are `Prt_or_Asm`, `Component`, `Feature`, `Annotation`, `Note`, `Location`, `Datum`, `3D Curve`.

As discussed earlier, the numeric code for the type is reflected in the code generated when selecting items in the search results. The type code for `Annotation` and `Note` are both 147, while `Prt_or_Asm` ("Solid Model" from the GUI) and `Component` are both 69.


By Name

The Search Tool allows case-insensitive name searches, and wildcards can be used to make the search criteria more generic. The basic syntax is as follows:

~ Select `selspecdlg0` `RuleTab` \
1 `Attributes`
~ Update `selspecdlg0` `ExtRulesLayout.ExtBasicNameLayout.BasicNameList` \
`NAME`
 
Examples of `NAME` with and without wildcards might be `12345678_OBSOLETE.PRT`, `DEFAULT`, `ASM_TOP`, `ASM_*`, `*65-5*`, `*side*`.


By ID

If a specific feature ID or note ID is known, this can be searched for as well. This appears in the GUI under the "History" tab and generates the following entry:

~ Select `selspecdlg0` `RuleTab` \
1 `Misc`
~ Select `selspecdlg0` `RuleTypes` \
1 `ID`
~ Update `selspecdlg0` `ExtRulesLayout.ExtBasicIDLayout.InputIDPanel` \
`IDENT`
 
Where `IDENT` is an integer number such as `1`, `2`, `3`, etc. Note that the History tab goes by the name of Misc in the trail file. All other tabs follow their name in the trail file more directly.


By Parameter Value

In addition to entity name searches, the Search Tool can perform searches based on parameter values, using the "Expression" radio option in the "Attributes" tab. Keep in mind that there are differences in the behavior of "Component" searches versus "Solid Model" searches. Testing will ensure your searches produce the desired results.

This sequences will prep the dialog box for searches based on parameter values:

~ Select `selspecdlg0` `RuleTab` \
1 `Attributes`
~ Select `selspecdlg0` `RuleTypes` \
1 `Expression`
 
The type must be selected first (real number, string, integer, yes/no), then the name of the parameter. Be careful when selecting the parameter name from the drop down list, because only a sequence number will be recorded. For a different set of models, the sequence number may not correspond to the same parameter name as when you recorded the trail files.

This results from choosing a parameter from the list:

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList` \
1 `51`
 
This results from typing in a parameter name:

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Input `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DES`
~ Input `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
 
The typed syntax can be simplified, by removing the 'Input' entries and leaving the 'Update' entry, to this:

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
 
The 'Value' field in the dialog box corresponds to the 'ExprValuesList'. Any value can be entered, and wildcards can be used as well. Note that string searches seem to be case insensitive only when used with wildcards.

~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprValuesList` \
`brack*`
 
The "Comparison" can be changed from the default of "is equal to". There are seven operators available, with this being an example of greater than (more useful for numeric comparisons):

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprOperandLabel`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprOperandLabel`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprOperandLabel` \
1 ` > `
 
The list of comparisons (for ExprOperandLabel) is:

` == `   is equal to
` != ` is not equal to
` < ` is less than
` > ` is greater than
` <= ` is less than or equal to
` >= ` is greater than or equal to
` * ` exists
` !* ` does not exist
 
When searching by parameter, the parameter type must be selected first.

~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList` \
1 `TYPEID`
 
Where `TYPEID` is 50, 51, 52, or 53 for Real Number, String, Integer, and Yes/No, respectively.


Look In

The 'Look In' drop down list allows for user control of the model (or hierarchy) to be searched. Here are some examples of selections made from the drop down list.

Top level selected:

~ Input `selspecdlg0` `LookInDrop` \
`12345678.ASM`
 
Component selected:

~ Select `selspecdlg0` `LookInDrop` \
1 `12345678_SKEL.PRT (12345678, id 43) (43)`
 
It is also an editable field in which you can attempt to enter model names. Unfortunately, the rather strong autocomplete nature may prevent entering the correct model name, or stop at another model, or result in garbage entered. None of this will produce a useful trail file.

The good news is that the syntax used for top level example can be used for any model at any level:

~ Input `selspecdlg0` `LookInDrop` \
`23456789.ASM`
 
This differs from other trail file entries in that typically the "Update" statement is kept while the "Input" entries are eliminated, because they are typically redundant. It is most likely the autocomplete functionality that makes this necessary.

When using this syntax, which lacks the component path (list of component ids), you'll lose some control if the model is used multiple times in an assembly hierarchy. Not a major problem, just something to be aware of. Based on my testing, the Search Tool uses the model that appears last in the model tree, if multiples exist.


Tabs

A specific tab in the Search Tool dialog can be selected using the following example:

~ Select `selspecdlg0` `RuleTab` \
1 `TABNAME`
 
Where `TABNAME` is `Attributes` for the Attribute tab, `Misc` for the History tab, `Status` for the Status tab, and `Geometry` for the Geometry tab.


Another Example

Combining several of these elements, here is an example that searches for parts and assemblies within all levels of ASM0002.ASM that for parameter DESC have a value matching "brack*", selects all found, and closes the dialog:

!!
!! Start the Search tool (via Ctrl+F)
!!
~ Activate `main_dlg_cur` `ProCmdMdlTreeSearch.edit_t`
!!
!! Select "Solid Model" as entity type to be searched for
!!
~ Open `selspecdlg0` `SelOptionRadio`
~ Close `selspecdlg0` `SelOptionRadio`
~ Select `selspecdlg0` `SelOptionRadio` \
1 `Prt_or_Asm`
!!
!! Restrict search to a subassembly
!!
~ Input `selspecdlg0` `LookInDrop` \
`ASM0002.ASM`
!!
!! Search all levels ('Include submodels' is checked)
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
1
!!
!! Go to "Attributes" tab, select "Expression" radio button
!!
~ Select `selspecdlg0` `RuleTab` \
1 `Attributes`
~ Activate `selspecdlg0` `selspecdlg0`
~ Select `selspecdlg0` `RuleTypes` \
1 `Expression`
!!
!! Select "String" from parameter value type pull down
!!
~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList` \
1 `51`
!!
!! Enter parameter name
!!
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
!!
!! Enter parameter value search string
!!
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprValuesList` \
`brack*`
!!
!! Perform search by clicking 'Find Now' button
!!
~ Activate `selspecdlg0` `EvaluateBtn`
!!
!! Select all in search results
!!
~ Select `selspecdlg0` `ResultList` \
-1
!!
!! Hit 'Close' in Search dialog (even though it says 'CancelButton')
!!
~ Activate `selspecdlg0` `CancelButton`
 

Both the Model Tree and Search Tool are useful when used in trail files. Use of the Model Tree is more limited because it requires knowledge of its contents before the trail file is generated. The Search Tool, when used properly, provides one of the most robust methods of performing selecting with trail files. With minor editing, trail files utilizing the Search Tool can be generated quickly, easily and can be applied to a wide range of models.


Next time: Mapkeys and Trail Files

Wednesday, July 2, 2008

Pro/WebLink: Tips On Getting Started

Pro/WebLink is one of the free PFC based API's available for automating Pro/Engineer. Although the documentation and marketing literature is focused on using Javascript with Pro/WebLink, VBScript can be used if that is more to your taste.

Developers interested in writing Pro/WebLink application have to overcome a number of hurdles. Most of these are related to the Internet Explorer and Mozilla security models, because Pro/WebLink applications typically must run within the context of the Pro/Engineer embedded web browser. This differs from the VB API (new with Wildfire 4.0), which runs outside of the Pro/Engineer process and has far fewer security issues to worry about.

While security is not the only problem facing Pro/WebLink developers, it is the most common problem in my experience. In this article I'll discuss the necessary steps in setting up your environment to run Pro/WebLink applications.

Pro/ENGINEER Configuration

Use of Pro/WebLink requires that the config.pro option WEB_ENABLE_JAVASCRIPT be set to ON (the default is OFF). In Windows, if this option is set to ON when Pro/ENGINEER is started, pfcscom.dll will be registered as a COM server. This contains all of the Pro/WebLink functionality.

Generally this works very well, but I have seen problems where the DLL doesn't get registered, or some other similar problem occurs preventing the Pro/WebLink application from functioning. The workaround is to run the application as an administrative user first, then the program works for everyone. Fortunately, I have only seen one user affected like this, otherwise the workaround would get really annoying.

None of that is relevant in Unix, as the required XPCOM technology is already present in the embedded Mozilla browser. However, I have seen rare instances where the Mozilla profile in the user's unix home directory has become corrupted. The resolution is to delete the profile. Pro/Engineer will recreate it upon startup.

HTML SCRIPT Tag

When setting up your Pro/WebLink programs, you are likely to include one or more files containing your Javascript code. A common one to use, although it is not absolutely necessary, is the PTC supplied pfcUtils.js file. If you are going to use such functions as pfcCreate() and pfcGetProESession(), you need to make sure you include pfcUtils.js correctly to avoid confusing errors, such as "Object Expected".

You also need to ensure that the SCRIPT tag entry in your HTML code correctly locates the pfcUtils.js file. For example, this entry will find the bom2excel.js file if it is placed in the same folder as the HTML file, and the pfcUtils.js file if it is in the parent folder:

<SCRIPT LANGUAGE="JavaScript" type=text/javascript src="../pfcUtils.js"></SCRIPT>
<SCRIPT LANGUAGE="JavaScript" type=text/javascript src="bom2excel.js"></SCRIPT>
 

Your web browser may not complain in an obvious way if it cannot find one of your Javascript programs, making the resulting errors hard to diagnose. If using a web server, make sure that the web server process has sufficient permissions to read the HTML and JS files, otherwise you'll wind up with the same problems, but it will that much harder to diagnose.

Web Browser Security Models

Overcoming the security requirements of Wildfire's various supported web browsers is often frustrating because the requirements are not inherently obvious and the documentation can be hard to find. With Wildfire 4.0, Mozilla is the supported browser on Unix platforms and Internet Explorer is the browser for Windows. Both have different mechanisms and rules concerning security.

Using digitally signed applications allow the developer to bypass some security roadblocks by requesting enhanced functionality based on the user's "trust" of the developer. Digital signatures are far beyond the scope of this article however.

Internet Explorer Security

Internet Explorer security is based on zones: Internet, Local intranet, Trusted sites, and Restricted sites. Each zone has it own security settings enabling or disabling certain functionalities. Using the "Custom Level" button, each option can be enabled or disabled selectively. If you change any of the security options, you may need to restart Pro/Engineer for the changes to take effect in the embedded web browser.
It is recommended that you do not reduce security for the Internet zone. It would be better to add the web site to the Trusted sites zone, then adjust the security for that zone.

Internet Explorer will decide to which zone your application applies depending on how you access it. If you access your program from a web server using a fully qualified domain name (i.e. www.yahoo.com) for a site that is not in your Trusted sites list, Internet Explorer will consider it part of the Internet zone. Using an internal web server (i.e. without top level domain: .com, .org, .co.uk, etc) or accessing the program from your hard drive or a network hard drive, will cause Internet Explorer to use the Local intranet zone. Not surprisingly, the Trusted sites zone will apply to a site that is in the Trusted sites list, even if it is an internal web server.

Pro/WebLink applications need a couple of settings defined for the zone that will be used by your application. Some of these may already be the default for you. As PTC recommends in the documentation, the option "Initialize and script ActiveX controls not marked safe for scripting" should be set to "Prompt". If you are interacting with Excel from Pro/WebLink, this option may need to be set to "Enable".


Ensure that the option "Active Scripting" is set to "Enable".

Mozilla Security

Mozilla has some good security functionality in which a script can request enhanced functionality allowing the user to accept or deny the request. That's why you see some UniversalXPConnect requests in Pro/WebLink examples. The code has to ask for enhanced privileges to connect to Pro/Engineer and do something useful.

When the Pro/WebLink application is served from a web server, the code and HTML must be digitally signed (together) for this request process to work. To make matters worse, a very unusual jar:http: URL must be used to interact with the resulting JAR file that contains the code and HTML.

A workaround is not to use a web server, but instead access the code and HTML from the file system using a file: type URL. For Pro/WebLink applications, the user is generally prompted only once for enhanced privileges, then is good to from then on.

Review

Keeping some of these issues in mind will help you get up and running with Pro/WebLink avoiding many of the pitfalls and frustrations.

  • Set WEB_ENABLE_JAVASCRIPT to ON in your config.pro file
  • Ensure that HTML and JS files are located correctly
  • Make sure that the web browser security requirements are satisfied