How To Deploy Globally

aras.comCopyright © 2013 Aras. All Rights Reserved.
DOMOREA C E 2 0 1 3

aras.comCopyright © 2013 Aras. All Rights Reserved.
A C E 2 0 1 3
How To Deploy Globally
Learn Aras’s methodology for
extending PLM to a global multi-site
environment

aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 3
Presentation Outline
 A Global Scenario
PLM systems tend to – or more realistically – need to grow beyond
local teams
 Deployment Steps
Specific steps lead to an understanding of needs and the types of
solutions that may be offered
 Customer Examples
Overview of customer examples to particular use case scenarios
 Q&A
 Note: Since this is a tech session we will not talk about global
project management or implementation methodologies

Important Points
 Global deployments always raises complexity in multiple
different ways compared to local deployments
 It is a good idea to prepare for both technical and non-
technical aspects of a global deployment
 In this presentation we discuss the technical aspects of
deploying PLM in a global setting… however challenges
may not lie in technology… do not under estimate the
human aspects like reluctance to change and training
 We recommend doing adequate planning and preparing
for a global deployment or the international extension of
an existing PLM deployment to remote sites
 Understand bandwidths, latencies, important use
cases, heavily used features, user profiles and
expectations

A Global Scenario
Global deployment:
• Two development sites in the US
• One development site in Japan
• Manufacturing in US, Brazil, Germany and China
• WAN traffic
• Local concept needs overhaul
Local deployment:
• One development site in the US
• Aras Innovator, database and
vault on the LAN
• Often the initial roll-out scenario
• Good performance

Step 3
Step2
Step 1
Approach
 Step 1: Use case optimization / globalization
» Understand the needs of your users at the remote sites
» Optimize through test / measures iterations
 Step 2: Vault distribution
» Local file storage
 Step 3: Vault replication
» Copy / synchronize files between vaults
 Step 4: Pinpointed measures
» Use case dedicated user interface

Step 1
Use Case Optimization Through Iteration
 Identify and optimize important use cases that need
to perform well in a global deployment
 Define / identify global use cases
 Create test cases
 Investigate
 Define measures
 Implement measures
EXAMPLE: A CAD designer in Japan may only login once in the morning, work on 3D
models and drawings the rest of the day and logout in the evening. Whereas an employee
on the shop floor may login multiple times a day to look in his or her in-basket.

Step 1
Use Case Optimization Through Iteration
Run Test
Cases
Analyze
Results
Define
Measures
Implement
Measures
Define
Use
Cases
Aras Innovator
Framework and
Solutions
WAN Topology
EXAMPLE:
1. Test login and BOM load in
Frankfurt (Germany)
2. Analyze data model and
methods on part form and
relation grids
3. Analyze WAN between Frankfurt
and Detroit
4. Adjust load behavior of part
form

Step 1
Use Case Definition Example
 Primary use case focuses on SKU (Test 1)
 Login
 Browse to SKU
 View SKU
 Create new SKU (no save)
 Secondary use case focuses on SKU Feasibility (Test 2)
 Login
 Browse to SKU Feasibility Steel
 Search for Items
 Browse to SKU Feasibility Alum
 Search for Items
EXAMPLE: Customer’s remote team is mainly focused on working
with SKUs in Aras Innovator

Step 2
Distributed Vaults
 Distributed vaults
 Central application and database (WAN)
 Files are on-site (LAN)
Remote Site Main Site
IIS
Vault 1Vault 2
Use cases that suffer from global deployments
typically involve moving files. EXAMPLE: CAD
designers working with large 3D-CAD assemblies.

Step 2
Distributed Vaults
 Aras Innovator architecture allows for independent vault servers separate
from the Innovator application server
 In a global deployment, each single site may have a vault server installed
to provide secure storage of files on the LAN
 Aras Innovator uses its central database to manage the metadata about
the files stored in the distributed vaults. The vaults do not have they’re
own database or login.
 Users have their default, local vault assigned
 Vault location is transparent to users (they don’t need to know which vault
has what file)
 Aras Innovator API allows for bulk file operations on vaults – e.g.
download/upload all files of an CAD assembly directly from/to a vault
hereby reducing traffic to the application server.

Step 2
Distributed Vault Definition by Admin

Step 3
Vault Replication
 Vault replication  Files are synchronized between vaults
 Aras Innovator knows which is the
actual source / copy
 Replication scheduling & events
IIS
Vault 1Vault 2

Step 3
Vault Replication
 No “master vault”: files are uploaded to a specific vault based
on a specific user’s selected Default Vault property
 Aras Innovator can replicate vaulted files across multiple vault
servers
 Allow users to retrieve files from their local vault, or from
another vault in any order of preference
 Replication works in a multi-step asynchronous process
 Replication rules define what is replicated, when and to which
remote vault(s)
 Vault Replication works on servers with subscriber licenses

Step 3
Vault Replication Definition by Admin
• Vault definition
• Replication Rule(s)
• User Read Vault Priority

Default Vault and Read Priority
Admin Tips
 A user’s Default Vault is the vault server where all files saved by the user are saved. For
systems configured for Vault Replication, it is also the preferred vault from which files will be
retrieved for a given user, unless specific Read Priority vaults are set.
 Vaults can be specified and prioritized for each user by setting one or more vaults, including
the User’s Default Vault, on the Read Vaults relationships tab for a User.
 When a user gets a file, Aras Innovator determines all the vaults with non-stale versions, and
will select the vault to send the file based on (1) if it is the vault with the highest Read Priority
(lowest numeric value), (2) it is the user’s default vault (if that vault is not in the Read Priority
list), (3) it is another vault.
 Setting the Read Vaults should be done for users to improve performance accessing
files, based on latency, bandwidth, server load and other considerations.
 A User’s Default Vault and Read Vault priority is also significant in triggering Replication. The
user’s Default Vault sets where a file is first saved or changed, so Replication Rules are set on
that Vault to generate onChange Replication Transactions.
 The Read Priority, and the Vault location(s) of the non-stale version of the file, determines
which vault Aras Innovator chooses to send the file, and Replication Rules enable the chosen
vault to generate onDemand Replication Transactions.

Replication Rules
Admin Tips
 Replication rules define which files get replicated, from where, to where, and when.
 Replication rules are checked when a file is downloaded from a vault server (this happens
when users get or view a file), when a file is uploaded to a vault server (this happens when
users add or modify a file), and when requested programmatically.
 Replication rules are created for each vault server, and can be written to move files to
another vault server or copy files to multiple vault servers.
 User Default Vault and Read Priority settings, as mentioned above, interact with Replication
rules, so care must be taken in defining both to work together to give the desired results.
 Replication rules are checked by the Innovator Server, and any match causes the creation of
replication transaction record(s) for the specified file and source vault to each target vault
specified in the rule.
 These transaction records are regularly checked by the Innovator Server based on the
settings determined in how the Replication Transaction thread was configured, and sent to
and executed by the Vault servers per the date/time the transaction is due to execute.

Step 3
Replication Rule Definition
Setting Description
Initiator Type Defines the initiating event to run this rule – onChange,
onDemand, onEvent.
Replication Mode Specifies the timing for executing a replication transaction –
Immediate, Delayed, Scheduled, Manual.
Replication Type Set the execution time specified in the Replication Time field
defined below.
Replication Time UTC time.
Timeout Maximum amount of time allowed from when a transaction
execution request is sent to a vault server and accepted
Filter Method Identifies a server method which is used to determine if a file
having a replication transaction record should be replicated at
the time the replication transaction is just about to execute.
File Types Specifies and restricts which types of files will be replicated.
Target Vaults Specifies the vault or vaults to copy the file to.

Replication Rules
Admin Tips
Initiator Type defines the initiating event to run this rule. Choices are –
 onDemand, for cases where a user belonging in the rule’s related identity tries to get the
physical file. In this case, target vault will be the highest priority ”read” vault of the user
initiating this request, and related Target Vaults (see below) will be ignored. If a file already
exists in more than one vault, keep in mind that the rule may or may not create a replication
transaction, depending on which vault the file is retrieved from. Therefore, you should
usually have similar onDemand rules for each vault to get consistent behavior.
 onChange, for cases where the physical file is added or changed by a user belonging in the
rule’s related identity.
 onEvent, for cases where a method explicitly requests replication checks be performed. The
user must belong in the rule’s related identity, or must be granted special temporary
credentials in the method through a GrantIdentity() call. onEvent replication rules are
checked when AML of the form <Item type='File' action='replicate' id=’…’ /> is sent to the
Innovator server for a specific file ID. Optionally, preferred vault(s) to replicate from may be
specified by adding the Located relationship(s) in preference order to the AML. However, if
none of the vaults specified have a non-stale version, or no vaults are specified, Innovator
checks for the first vault with a non-stale version.
 OnDemand and onChange events are automatically checked when a get or
upload, respectively, occurs for a specific file on a vault. To replicate files for any situation
other than these, use a method to pass File Item ID(s) with a replicate action, and create a
matching onEvent rule.

Step 4
Custom UI Forms
 Pinpointed Use Cases: Custom UI Forms
IIS

Step 4
Custom UI Forms
 Goal: the custom form(s) shall constitute a static UI
outside of Aras Innovator
 Effect: relative to the specific scenario, eliminate
unnecessary requests to the server
Slide 21

Step 4
Custom UI Forms
 The main use case for initial deployment if working
with Documents and CAD assemblies:
 Standard remote use cases addressed by Aras integrations:
1. The CAD Connector will reduce the interaction with the client
performance when working with CAD Items
2. The Office Connector will reduce the interaction with the client
performance when working with Document Items
 Other typical remote use cases:
 Add a custom InBasket to allow voting
Slide 22

Step 4
Custom UI Forms
 Step 1: heavily used target use cases
 Search / View 3D model, drawing
 View part data
 Edit part data
 View BOM
 Step 2: build targeted, optimized, static forms
(e.g. smaller HTML / JS footprint)
 Load UI form once
 Load data from server on demand (AJAX)

Step 4
Custom UI Forms – Example
 Aras Subscriber Portal
Slide 24

Step 4
 Aras.com Web Site
Slide 25

Step 4
 Aras.com
Project Site
Slide 26

Customer Scenario
Solution Overview
Main use case:
Document viewing
Main use case:
CAD Design Main use case:
Document viewing
Main use case:
CAD Design
Main Site
Main use case:
SKU

Customer Scenario
Possible Measures
 Use Case Optimization SKU (Test 1)
 Fix JavaScript error in SKU form
 Install and enable Dynamic Compression
 Change SKU ItemTypes to use Page Size 200, Max Results 1000
 Change "Plant Feasibility" (SKU Plant Feasibility) to Tab Order to
load as the first relationship tab
 Update Show/Hide Method used in SKU Forms to reduce wait
time to 10ms (Tuned custom JavaScript)
 Remove foreign properties from the SKU Plant Feasibility and
SKU Plant Feasibility Steel ItemTypes
 Change Starting page per user
Customer
Example

Customer Scenario
Possible Measures
 Use Case Optimization Design Sites
 Use File Replication
 Configure replication times during low network traffic
 Use Case Optimization Manufacturing Sites
 No local vault
 Implement custom document download/viewing page

Step 0
Service Pack
 Newest service pack
 Service packs may implement issues addressing global
deployments
 Check if new service packs enhance your use case before
starting a global deployment project

Global Deployment
Network and Non-Technical Aspects
 Network Configuration (WAN)
 Bandwidth
 Latency
 Gateways and Proxies
 Network accelerators
 …
 Non-Technical Aspects
 Project Management Methodology
 Process analysis and design
 Communication
 Testing
 Training
 Documentation
 Hotline / User support
 …

Questions?

How To Deploy Globally

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie How To Deploy Globally

Ähnlich wie How To Deploy Globally (20)

Mehr von Aras

Mehr von Aras (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

How To Deploy Globally

Hinweis der Redaktion