DBWorks or Agile

There was a presentation at SWW about a product called StructureWorks. The guy who wrote it was there and had tied it into JDE. The presenter might be able to shine some light on JDE.

snipped-for-privacy@etcc> We are currently looking at DBWorks or Agile for implementing PDM/PLM

I think he's looking for input on DBWorks or Agile. JDE is a lock.

Yep. Looking for pros/cons for DBWorks or Agile.

We already have JDE. Trying to figure out how easy it is (if even possible) to tie them together.

Thanks again for any help.

We use DBWorks and I am fairly experienced with PDMWorks, enough so that I know I really like DBWorks over it. But I have never used Agile. Send me an email and we can talk a bit more about my experiences with DBWorks.

Other than that what exactly are you looking at. They are both fairly complex products just to give general impressions.

--Matt 'mfeider bigfoot com'

snipped-for-privacy@etcc> We are currently looking at DBWorks or Agile for implementing PDM/PLM

Hello,

Could you provide more information on what you mean by "tie" the programs together.

ERP/PDM integration is a big complicated process depending on what you want to accomplish. Somethings are easier than other. Full integration is expensive but simpler semi-automated process would work depending on the number of item masters and BOMs you process on a weekly or monthly basis.

What are the top 5 or 10 features that you want to see assuming either PDM system could do what you wish.

If you could provide more detail I could tailor the answer to your specific requirements.

Regards,

Len K. Mar, P.Eng. President, E-data Solutions.

Basically get information from DBWorks into JDE. Rev levels, mass (for shipping), and other things that we haven't really thought of yet.

We aren't going to, as far as I know, go back and vault everything we have. It's more like, "we start HERE with a PDM system and enter old files as needed (ECNs)".

Wish list:

1) Organize files (I know this can be done) 1a) "Easy" to learn. 2) Notify people of ECNs for approval so hard copy packets aren't necessary. (I believe this is workflow in DBWorks.) 3) People within our company can access the latest drawings only (PDF) 4) Specified vendors can access our PDF, STL, IGS files as needed. 5) Notify vendors when changes to parts have been made. This is helpful on tight timelines when working with people half way across the world. It could save a day or two. 6) JDE could extract data to help minimize user input on that level.

Thanks again for everone's advice and willingness to help.

See comments below:

What revision schema do you use and how do you number files?

Relative term :)

Workflow can be set up. You will need to purchase the DBWarm module in order to authenticate users and their rights/permissions.

DBWorks has a new Master Document Mode that auto generates PDF's of SW drawings. You can write script to place approved documents where the ERP system can see them (item master). Better know what your doing here or you can get yourself in a world of hurt. Or you can decide ERP is for purchasing and have production just look at the DBWorks released database (shows major revisions only - minor revisions being worked on by engineering don't show up in production)

Depends where you store them and at what stage. Might want to look at the getting the DBWorks Web product that allows vendor to look at specific folders and the files within them. Opens up whole bunch of other issues with respect to security and IP.

Could set up DBWorks to send out emails to vendors when you check out a set of documents or change a set of documents.

Use DBWorks BOM Wizard to create an intermediary file that is imported into JDE. Alternatively, you could write script to send BOM directly to JDE (Dangerous and I wouldn't advise it).

I'd create an JDE user in DBworks that allows only that user to create a export BOM that JDE would accept. I'd then use standard import funcition in ERP system to import the file. Set up DBWorks to validate the BOM from ERP values prior to creating the ERP BOM for import - sounds more complicated than it is.

Note - this is for a one time push of new items/boms into JDE. Its a whole other issue trying to maintain ERP/PDM integration of item masters controlled by the ERP system. ESPECIALLY ONCE YOU TOUCH THE ACCOUNTING MODULE.

Len

A question about DBWorks. How does it store SW files?

DBWorks does not have the traditional limitations typically associated with vaulted applications. Instead of using a vault, DBWorks enforces a repository. The DBWorks repository offers plenty of flexibility as well as scalability. Administrators with the appropriate authority can add and/or remove definitions used for the storage of physical files. This flexibility allows organizations to welcome structural changes when they happen while at the same time it also ensures data structure integrity. DBWorks can take advantage of advanced OS security (DBWServer supports ACLs) and does not encrypt or mangle document names. This eliminates the possibility of problems associated with the recovery of multiple parts or with software revision updates. For More information you can contact snipped-for-privacy@na-ips.com

DBWorks does not have the traditional limitations typically associated with vaulted applications. Instead of using a vault, DBWorks enforces a repository. The DBWorks repository offers plenty of flexibility as well as scalability. Administrators with the appropriate authority can add and/or remove definitions used for the storage of physical files. This flexibility allows organizations to welcome structural changes when they happen while at the same time it also ensures data structure integrity. DBWorks can take advantage of advanced OS security (DBWServer supports ACLs) and does not encrypt or mangle document names. This eliminates the possibility of problems associated with the recovery of multiple parts or with software revision updates.

Guess you 'll have to explain the difference between a repository and a vault. How does DBWorks maintain older versions of the same file?

What is the difference between a repository and a vault? Where are the files stored?

You can save them where ever you want, normally you just pick a drive on your network i.e. S, and store the documents there..

What is a repository and how is it different than a vault? If document names are not changed how does DBWorks handle revisions?

associated with

software

snipped-for-privacy@na-ips.com

So if I save a file anywhere it could be on my local machine. DBWorks would dutifully log it but nobody else could access it unless it was in a shared folder. It would seem that having files in a somewhat fixed location would be advantageous from the standpoint of backup which is what vaulting assures.

Conceptually what is a repository? Is it off limits to anything but DBWorks? Does it, must it or can it have a folder structure?

Also, how then does DBWorks deal with revisions. Where are the old documents stored and how are they differentiated from the latest document? I have been reading the manuals and haven't quite figured this one out.

P.

The primary difference between a true vault and a repository (depending on whose definition you use)is the former encrypts the file with a proprietary format. The latter uses standard MS file locking techniques to control the file permissions. In the event of a catastrophic failure a system administrator could release your files to be worked on. This is not true of an encrypted system.

In a typical shop - files are share either in common folders, local hard drives, etc.... Having a central repository where everyone works off of the latest version is a better idea. DBWorks just ensures everyone plays nice. This is especially true of projects that use shared files such as SW Toolbox and the infamous "Giant Screw" (pun intended).

Set up (Conceptual)- Shared installation - requires DBW Access Rights Manager (DBWarm) add-in.

System administrator creates two user security groups: DBWDomain and DBWorks Power Users. A special user called DBWServerAdmin is also created (more on this latter).

System adminstrator creates two mapped drives. The first (i.e. N:\DBWorks_Shared)has its permissions set to DBWDomain security group. The second mapped drive is the repository or vault (i.e. Z:\Secured Files). A special batch file is run against this folder which assigns file locking permissions to DBWServerAdmin user. This is a one time operation.

DBWorks Adminstrator logs into DBWarm and assigns individual users various DBWorks permissions (i.e. Managers have a different set of tasks they can perform vs. junior engineers). Usually set up per departmental or functional groups. To work properly the user names need to map one-to-one with the NT domain login. (i.e. snipped-for-privacy@edatasolutions.local is my domain login - my DBWorks\DBWarm login is lmar as well)

DBWorks Administrator opens up Category maker program and under tools sets the path to the secured storage area (i.e. Z:\Secured Files). This is a one time operation.

System Administrator sets up each DBWorks client with a MS Service called DBWService. It is set up with the special user login called DBWServiceAdmin. During the client installation, DBWorks will ask you for the shared folder location (i.e. N:)

I won't get into category maker but it basically determines your file folder structure (if you want one). You can classify a file when you save it which will autonumber the file and place it in a special folder within the "vault". As an example I have DBworks map the SW Toolbox Data folder to a special location and then have any files located within the folder or sub-folder as "no revsions). Toolbox files/configurations are mapped with a little red "X" within DBWorks and they are not revision controlled.

Once system is set up (I've ommitted a few items) the system acts as follows: (I've turned on Dataentr.lst under environment)

User starts up SW and turns on the DBWorks Add-in. DBWorks checks that your NT login matches your DBWarm login. User creates a new SW part and selects DBWorks save. User categorizes part file and dbworks issues new ID number and places file onto Z: drive (i.e. Z:\Secured Files\Parts\example\lentest.sldprt}. State is new (green square). If you were to look at the permissions on the file it would have DBWDomain and DBWServerAdmin. Note - you must go thrugh DBWorks Client in order to change permissions on a file.

The first time someone checks out the file for exclusive control you bump up the revision. DBWorks checks to see that you have permission to check it out (red)(As determined by your DBWarm settings)and then uses the DBWServer service to reset permission of the file. Permission on the file will now show DBWDomain, DBWServerAdmin,and snipped-for-privacy@edatasolutions.local - everyone else opening the file will receive a read-only flag.

Two additional files are created. __DBWUNCHK__PART1.SLDPRT and PART1.SLDPRT.___.gz at this time. They are placed in the same directory as the original PART1.SLDPRT file. The former is used if you need to uncheck out the file (decide not to make changes at this time) and the latter is the first revision file - it is a zipped .gz file. Thus, subsequent revsions will take on the file names PART1.SLDPRT.01.gz, PART1.SLDPRT.02.gz, PART1.SLDPRT.03.gz, etc... depending on your revision schema.

Thus, as time goes on you will have a series of files that are automatically created that maintain the history of the design. You can go back to any previous revision and make it active. Note - this works for assemblies as well which shows you what revision of the parts were used for a particular assembly revison.

Hope this helps.

Len K. Mar, P.Eng. E-data Solutions

Ken,

I really appreciate you taking the time to go into this detail.

A couple observations/questions from the viewpoint of someone who has used PDMWorks. PDMWorks, which is said to be vaulted actually just mangles the filename and puts the file into a directory with the name of the revision. There is no effort to compress the file to save space. DBW appears to use renaming and gzip to make a unique and SW non-accessible file. PDMWorks places copies of the SW files on the local machine. Does DBW bring the file directly into memory or does it make a local copy and then work with the file until it is checked in or the user is done working with it? In other words, if I check out or copy files can I leave them on my machine or take them home as necessary?

Len K. Mar wrote:

P.

Your observations regarding the differences between PDMWorks and DBWorks is the clasic example of file folders vs. database PDM's. Simply stated: I can do more with an open sourced database PDM system than a file based system. I used and customized PDMWorks in a production environment for three years before switching to DBWorks.

DBworks can work by either pulling the files directly from the repository on the file server (common) or you can set up DBworks to run in "local" mode where the files are copied to your local drive. Most companies pull the files directly from the server and dispense with having to copy the files locally. I must admit, I don't miss having to constantly check that my local drive matches the PDMWorks vault.

DBworks also has a briefcase mode where you can check out files and zip them up. You can then send them home, work on the files, and then bring them back to work. File locking prevents your co-workers from altering the files until you check them back into the system. This is one area I have little experience with and I'll defer any futher explanation to someone who knows more.

Another difference between PDMWorks and DBWorks is the open API of DBWorks. In order to program PDMWorks you need to purchase the Advanced Server. This gives you the API functions but you need to develop the code. DBWorks uses VBScript which anyone with basic programming skills can pick up fairly quickly. There are more than enough modules and example files to allow you to cut-and-paste new functions. You get this with the basic package.

Hopes this helps.

Len