7 Replies Latest reply on Aug 11, 2010 8:18 AM by Barry Stump

    DMZ Vault

    Barry Stump

      OK if I wanted to limit external engineering (or other) access to a DMZ Vault yet have the Production (Final) versions in the Internal (More Secure) Vault, how might I best set that up?  Can a Workflow in the DMZ Vault be set up to move files to the Internal Vault at a certain Life Cycle state?

        • Re: DMZ Vault

          You would have to have a custom program to move the files to another vault. The custom program could be initiated by a workflow state change.

          • Re: DMZ Vault
            Jeff Walters

            Barry the first question that comes to mind is do you want to maintain the history of the file. If you do moving it to a different vault will not work without a lot of special code. A simpler solution might be to make two root folders in your vault “Internal” and “DMZ”. The advantage is with permissions you can control who sees the directories, each one can have their own workflows, you can use workflow links to move the file from one workflow to another, maintain the history of the files, and you only have one database and archive to backup and maintain.

              • Re: DMZ Vault
                Barry Stump

                Ye sthat works great for me but I am not so sure IT will like it.  They typically restrict ouitside acces thru 4-5 layers of protection.  Letting easy access means opening up up to DOS attacks etc.  Hence the desire for a DMZ outside the main world.

                • Re: DMZ Vault
                  qinghai jin

                  Barry the first question that comes to mind is do you want to maintain the history of the file. If you do moving it to a different vault will not work without a lot of special code. A simpler solution might be to make two root folders in your vault “Internal” and “DMZ”. The advantage is with permissions you can control who sees the directories, each one can have their own workflows, you can use workflow links to move the file from one workflow to another, maintain the history of the files, and you only have one database and archive to backup and maintain.( I strongly agree with this)

                   

                  I used archieve and working folder to deal with the problem. in the mean time, break the whole system files into different computers.

                  For my application, four computers were connected to construct the whole integration system.

                   

                  Computer A--Installed SQL Server . Store the history of operations and customers/projects/products data.

                  Computer B--Generated SW models and its follower documents PDF, INI,etc.

                  Computer C--Generated and Stored Project Reports in Excel. Source templates and models were stored on this computer too.

                  Computer D--Generated Accounting Files, BOM, shipping slip and Inventory up-to-date list.

                   

                  Control the working sequence of these four computers within one system using the logic switches/project check points in SQL Server. for the left three computers, there are diff. applications on its own working flow. Every computer has to  'report' what it did and 'wish-list' to SQL server within the same project. Of course, all computers are physically connected together on the same intranet.

                   

                  In terms of data management, computer A works as the system's CPU. the others work as antenna. but my application can run at any computer after minor manual set-up the application(within 2 minutes) because it can detect the matching SQL server's location.

                   

                  Hello, Barry, Sorry to follow to learn your PDM's ideas/progress here.