DBWorks or Agile

We are currently looking at DBWorks or Agile for implementing PDM/PLM
capabilities. We also are looking to tie this into our JDEdwards
program.

Is anyone out there using one of these packages? What are the
pros/cons of the package you are using?


Any input would be appreciated.

Thanks

 

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.

 

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 <at> bigfoot <.dot.> com'

 

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

 

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?

 

What is the difference between a repository and a vault? If DBWorks
doesn't change document names how does it store SW file of old
revisions?

 

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.

One thing I'll say about DBWorks. Making the manuals available is so much
better than the marketing blather on many of the other PDM sites including
Agile.

 

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.
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
- 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?

 

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