Working with iFolders….huh?

During ProjectWise Administrator training, many students stumble over the concept of a ProjectWise Project. Users have often told me, “but we do not have projects”; they have Assets, Stations, Jobs, Work Orders, Facilities and so on. So terminology has caused some natural confusion. As I was recently explaining the concept of a ProjectWise Project and how it differs from a basic folder, it dawned on me; for training purposes, I will use the term “iFolder”; short for an intelligent folder.

When you think about it, a ProjectWise folder is really no different from a Windows folder. It is a dumb container of files, with little built-in or configurable attribution. But a Project – excuse me – iFolder can do so much more. For example, each iFolder can contain their own attributes, saved searches, documents, sub-folders, components and limit other ProjectWise resources (more on this later).

For every new iFolder that is created in ProjectWise Explorer, the user creating it has the option to classify what iFolder “type” it is. For example, perhaps you are creating a real-world iFolder for a hospital, pharmaceutical plant, transmission line, electrical substation or office building. When you select the iFolder type, you can define its properties, such as project number, project manager, location, start and finish dates, and other relevant information setup by your ProjectWise Administrator. If you are familiar with a ProjectWise environment (a database table that stores document attributes), then think of iFolder properties as configured attributes for your Asset, Station, Job, Work Order, Facility and, yes, Project.

An iFolder can exist anywhere in the datasource; you can create them at the root of the datasource, inside a folder, or inside another iFolder. You can use existing iFolders to create a new one, or you may decide to create one or more iFolders from a template. If the latter is the case, your Administrator would create and store all the template iFolders under a single folder in ProjectWise Explorer, and then in ProjectWise Administrator, set that folder as the default for all iFolder templates. This way, when users create iFolders in ProjectWise Explorer using the Creation Wizard, they are automatically offered the list of iFolder types that exist in the default iFolder template folder, from which they can select one to use as the basis for their new iFolder.

As mentioned earlier, you can also tailor resources within an iFolder. Think of an iFolder resource as a subset of your datasource resources, such as applications, departments, environments, storage areas, views, workflows, workspaces and rendition profiles. You can select these Resources when you initially create the iFolder, or modify them later from the Resources tab of the iFolder Properties dialog. An iFolder can either inherit resources from its parent iFolder, from the datasource, or it can have its own subset of resources.  So, for example, I could restrict access to all ProjectWise storage areas except the one required for a particular Asset, Station, Job, Work Order, Facility and so on.

Hopefully the term “iFolder” helps you clarify the definition of a ProjectWise “Project”. As with many other ProjectWise commands, there are several configuration notes for ProjectWise Projects that you need to be mindful of, including but not limited to:

– Limits: Each Project can contain 750 sub Projects. Conversely, a Project sub-folder structure is limited by the same datasource rules as any typical ProjectWise folder structure.

– Product Requirements: Be mindful of the Bentley components you work with. Several products, including Bentley Substation and Bentley Transmittal’s will only align themselves with a ProjectWise Project, not a folder.

– Permissions: There are separate ProjectWise settings (for each user) that allow for the creation and manipulation of a ProjectWise Project. Consult with your ProjectWise Administrator for details.

Advertisements

Stamp of Approval

Most ProjectWise users understand the difference between “customization” and “configuration”.  In short, the former generally refers to using the ProjectWise SDK to develop C++ programs that will alter existing or create new options in ProjectWise.  The latter uses nothing more than built-in processes to extend delivered ProjectWise functionality.  In my experience, most users fall into the configuration category; it is cleaner and easier to maintain a ProjectWise system, plus many users have neither the in-house expertise nor budget to modify code, relying only on ProjectWise out-of-the-box features.  In these instances, I will work with users to try and develop configuration that can achieve their desired result, so long as it is not a large administrative or end user burden.

One such challenge was a recent request to have an event-driven “stamp” placed across a drawing title block.  This is not a process that can be easily automated, but I began thinking that I could come close by using four core components of ProjectWise: a workflow, document attribute, Attribute Exchange and the new Rules Engine.

For those of you not familiar, the Rules Engine (introduced in the ProjectWise SELECTseries 4 .559 build) is a new ProjectWise Explorer extension that allow administrators to configure document processing events for each State in a Workflow.  When the Rules Engine is applied to a Workflow, it replaces the standard ProjectWise Explorer Change State commands (Next, Previous and Change) with user-defined operations.  A Rule can be defined to run a set of “Actions” that are configured to run in a specific, sequential, order.  The Action is a ProjectWise task that may be carried out on the document – such as setting an attribute value – before changing the document State.

Armed with this new idea, I worked with the user to develop a stamping process.  Their need was to clearly mark a PDF (or Plot) as PRELIMINARY or SUPERSEDED in their title block, automating the process as much as possible.  This user does not use ProjectWise Workflows, so I created a mock one, which contained only one state.  In this case, the name of the State (Approved) and Workflow (Stamp) is arbitrary since their usage is only to link to the Rules Engine.  Next, I added an attribute (Stamp) to their existing ProjectWise Environment.  The Stamp attribute does not require any special value settings, although it may later.  Therefore, the Stamp attribute starts out blank:

Stamp AttrTo ensure that only the Rules Engine updates this attribute, it is configured as “read only”.  Next, I created a MicroStation Tag Set and Tag (both named Stamp), with the tag itself placed in the drawing title block on a 45 degree angle in a light gray, block font.  Like that Stamp attribute, the Stamp Tag is blank to start.  I then created a corresponding ProjectWise Attribute Exchange Class Name and Attribute and “bound” it to the MicroStation Stamp tag.

With the configuration complete, I can start the stamp process.  First, the users highlight the drawing(s) that require the stamp, right-click and select Change State.  Since the Rules Engine is attached to my Stamp Workflow, the standard commands Next, Previous and Change are grayed out and replaced with my new Actions:

CaptureIf I select the “Stamp PRELIMINARY” option, I am presented with a confirmation dialog box:

Stamp ConfirmSelecting Yes automatically updates my Stamp document attribute to PRELIMINARY.

Stamp Attr - PRELIMWhen I open the MicroStation drawing, the Attribute Exchange process runs, placing the Stamp attribute across my title block as desired:

Stamp Attr Exch

Keep in mind that this simple process can be imbedded in a deeper, more complex Workflow strategy.  As with many other ProjectWise commands, there are several configuration notes for the Rules Engine that you need to be mindful of, including but not limited to:

Setting an Attribute:  There is a Rules Engine variable called SET_ATTR (1 of 8 variables) that will populate a ProjectWise Environment attribute automatically.  However, it can only populate Environment Attributes and not standard ProjectWise attributes such a Description.
Working with existing Workflows:  When you configure the Rules Engine, you identify what Workflow it will run on top of.  It will not affect any other Workflow in your datasource
Condition Checks:  Using the Rules Engine, it is possible to check on whether or not an attribute is populated before changing a document(s) to the next State in the Workflow.  However, it does not validate what is in the field.
Permissions: Although the Rules Engine can override or disable some standard ProjectWise commands such as New Version and the State Change commands, a user must have the relevant ProjectWise rights to carry out these actions.

What’s in a Name?

Hello and a belated Happy New Year!  Okay, so part of my New Year’s resolution was to post a blog a month.  It looks like I cut it a little too close.  Maybe I should officially change that to averaging a blog a month.  Ah, such is life as a ProjectWise consultant (hmmm, there is my next blog!)  Anyway, I digress.

I have had several requests over the last couple of months from users who are trying to establish a specific naming convention for documents being created in ProjectWise.  This is always a polarizing topic, spanning all verticals/disciplines.  ProjectWise does provide a mechanism to aide users with this process – albeit with a few kinks – called Document Coding (referred to as “code” for this post).

A code is simply a process that allows a user to uniquely name a document in ProjectWise, using a combination of Environment attribute fields separated by a character (or not).  While almost every organization can take advantage of a code, most will have different requirements.  Let’s take a look at a recent code I developed for one of my users:

DC_1

PW Attribute Tab

In this example, the user had 6 requirements for their document name/filename: Year, Job, Unit, Discipline, Index and serial number (Seq).  The first step is to create a ProjectWise environment, which contains an attribute for each required code field.  In addition, I created (among other attributes not related to the code) a Drawing Number and Activity Description field.

Each attribute can be setup using a variety of ProjectWise options.  For example, the Year and Job (number) are automatically populated from their ProjectWise Project ‘Property’.  The Unit field is a basic ProjectWise attribute ‘Pick list’, while the Discipline and Index fields use the slightly more complicated ‘Look Up table’ methodology.  A Look Up table provides a user the means to develop pick lists using tables created in ProjectWise Explorer.  This allows a user the ability to add options to the pick list without having access to either ProjectWise Administrator (rarely) or the ProjectWise database (never).

The Discipline and Index fields form a ‘cascading’ pick list from the Look Up table.  In short, the options available in the Index are directly related to the Discipline selected.  The Seq or Serial Number field will automatically select the next available sequential number.  The Drawing Number field is a ProjectWise attribute identified by the code as a ‘Placeholder’.  This placeholder stores the complete code string, which can be delineated by a character.

The user requirement for this code presented an extra challenge.  The Index field is a 2-digit code that represents some sort of document type within their organization.  When the code pick lists are finished, there will be dozens of Index numbers (01, 02, 03, etc.) for each of their approximately 2 dozen Disciplines/Departments.  Users do not know, just by looking at the Index number, what type of document ‘Activity’ it is.  So the Index field had to include both its index number and description.  However, the description could not be part of the document name/filename when created.  This was achieved by writing a SELECT query in the Index attribute field that stripped the Activity Description from the Index field and place it in the Activity Description field.

As you might expect, the code process comes with pros and cons.  The main con is a Document Code can be broken.  Therefore, when using a Document Code, take into account the following:

A Document Code uniquely names a document based on a ProjectWise environment:  Many users believe it uniquely names a document within the datasource.  Not true.
A ProjectWise environment can only have 1 document code assigned:  If you have separate requirements for multiple disciplines/groups, this may constitute the need for a separate environment.
The Advanced Wizard (1): Is the only mechanism that works with a Document Code.  If a user creates a document using ‘No Wizard’, the Document Code is ignored.
The Advanced Wizard (2): Ensure that the Document Properties screen in the wizard is disabled.  If it is not, a user can overwrite the name/filename created by the code.
The Advanced Wizard (3): If you enable the ‘Create Document’ or Completion’ screens  in your Advanced Wizard (which appear after the Document Code screen), the user can hit the ‘Back’ button, which will automatically enable the Document Properties page, even if it is disabled!
No Wizard: Use of this option bypasses the Document Code, even if the parent folder has the environment set.  Note that this is working as designed.  It provides flexibility to create multiple document types within the same environment.  For example, you might create a Document Code for use with CAD drawings only.  However, the same environment may be used for other types of documents.
The Attributes > Document Code command: Look at the snapshot above.  All of the code fields appear to be read only.  Perfect!  However, that is not possible for the attributes that are pick lists.  They are simply greyed out because they are attributes of the code, which appear as read-only on the Document Attribute Tab.  If a user uses this command, they could modify the code attributes.
The Excel Import/Export Tool: Care must be taken when importing documents that are associated to a code.  The Import tool does not read or validate these attributes.
Code Field Separators: There are several default characters that you can select from.  But did you know that if a character is not listed (for example, the ‘_’),  you can simply enter it as your deliminator?
Document Code Restrictions: Restricts users to a range of numbers when creating a document code. Three types of restrictions can be created: Allow, Forbid, or Reserve.

If some of these options frustrate you (as it does me from time to time), consider that having a Document Code in place is usually better then having no process at all!  Many of these issues can be avoided with proper internal ProjectWise training and good security practices.

Disabling MS Office Integration

A new feature delivered with the ProjectWise SELECTseries 4 Refresh is the ability to enable or disable ProjectWise integration within your MS Office applications.  In the past, you could only disable the integration by re-running the ProjectWise Explorer installer and deselect the iDesktop integration for specific MS Office  product(s).  With the Refresh, you can now do this with a click of a button from inside the MS Office application.

But, where is it?  I will use MS Word as an example.  Simply open Word from your workstation and select the ProjectWise tab on the pull down menu.  Here you will find the Integration button, which is either set to ‘Enable’ or ‘Disable’, depending on how ProjectWise Explorer was installed on your workstation.

Office ButtonIf the ProjectWise integration was enabled, simply click the Disable button.  No need to hit ‘Save’ in MS Office.  Further, this setting is remembered the next time you start MS Word.  Lastly, this button is not available (it is greyed out) when opening a MS Office document stored in ProjectWise.

Remember, this is only available with the ProjectWise SELECTseries 4 Refresh.  To determine if that’s the version you have installed, open ProjectWise Explorer and do a Help > About ProjectWise Explorer.  If the commercial release is 08.11.11.559, you are good to go!

Customizing your Bentley Transmittal Portal

Anyone that is currently using Bentley Transmittal Services (BTS) has likely noticed the “customizable headline” notation on the BTS Portal log in page.  However, did you realize that it is quite simple to alter both the logo and verbiage to meet your needs?

To modify the Portal logo, simple replace the existing TransmittalsPortalLogo.png file located in the …Program Files\Bentley\Transmittals\portal\contents folder.  To change the “customizable headline”, edit the _Layout.cshtml document located in the …Program Files\Bentley\Transmittals\portal\views\shared\ folder.   Change the text line <span>Your text </span> class=”ClientHeader”>@View.Layout_CustomizableHeadline.

INETPUB

While installing ProjectWise Publisher recently, I ran across an issue where I could not load (view) a document via the ProjectWise Web Server.  The specific error received was “ACL is not in canonical form and therefore cannot be modified.”  Thanks to Ranveer and Bentley TSG, the problem was traced back to INETPUB being installed on the server’s local D: drive.  Apparently the ProjectWise Web server has some imbedded code that assumes INETPUB is installed on the local C: drive.  Ranveer has posted a link with more specific details on Be Communities.  You can find it here:  http://communities.bentley.com/products/projectwise/content_management/b/weblog/archive/2013/08/06/webserver-deployment-fails-due-to-server-acl-is-not-in-canonical-form-and-therefore-cannot-be-modified.aspx.

 

Microsoft Indexing Ignored Words

I am essentially re-blogging (sort of like a retweet?) from one I wrote for ‘Jo West’ about a year ago.  When indexing text for in ProjectWise, the ProjectWise processor FTR (Full Text Retrieval) uses the Microsoft indexing service to extract the text and stores it in the bentley-index.  We have all heard about the Microsoft Indexing “ignored” words such as ‘and’, ‘as’ and ‘the’. In case you are curious, here is a fairly complete list of the words that the Microsoft Indexing catalog will exclude:

A – about after all also an and another any are as a
B – be because been before being between both but by
C – came can come could
D – did do does
E – each else
F – for from
G – get got
H – had has have he her here him himself his how
I – if in into is it its
J – just
L – like
M – make many me might more most much must my
N – never no now
O – of on only or other our out over
R – re
S – said same see since should so some still such
T – take than that the their them then there these they this those through to too
U – under use
V – very
W – want was way we well were what when where which while who will with would
Y – you your

In addition, individual letters and numbers will also be ignored. Interestingly, adding a suffix to the ignored words will get indexed. For example, “get” is ignored, but “getting” is returned.