(ATS4-PLAT03) Balancing Security with access for Development
Lynn Miller
Principal Technical Support Scientist
LynnMilleraccelryscom
The information on the roadmap and future software development efforts are intended to outline general product direction and should not be relied on in making a purchasing decision
It is important to establish policies that ensure that the often-conflicting needs of administrators developers and end-users are met in a balanced way appropriate for your environment
In this session we will discuss the commonly reported pain points and outline the types of policies and procedures that that can help bring harmony
Be prepared to discuss your own experiences
Introduction
bull Administrators of Pipeline Pilot servers wish to have a controlled environment to ensure that ownership and access is properly identified and enforced
bull Protocol developers desire the ability to quickly easily publish protocols and updates for personal and production use
bull End-users need deployed applications to be accessible tested and maintained
Overview
End Users interact via interfaces like Web Port
bull Frustrated when process to gain access is difficult
bull When impersonation is on user-specific resource access issues can arise
bull Access to network resources user folders etc
bull Who to call if the published protocol breaks
bull Performance issues when server is not properly sized
Concerns raised by End-Users
Developers interact via the Professional Client
bull Issues with testing and deployment without a separate Development Server
bull Lack of uniform access to key resources across Development and Production (ODBCJDBC 3rd party tools disk paths etc)
bull Lack of consistent XMLDB folder structure between Development and Production servers make deployment unnecessarily difficult
bull Access to a defined location for storing shared reports particularly interactive reports which are best hosted on the Pipeline Pilot server
bull Frustrated by imposed policies that require extra effort or approval for protocol publication
Developers What would you like to add
Concerns raised by Developers
bull Lack of defined production protocol publication approval process makes it hard to get sign-off for upgrades and changes
bull When published protocols lack documentation and a defined owner the admin doesnrsquot know who to turn to when a user reports an error
bull Lack of distinction between Development and Production servers
bull Lack of coordination when multiple servers are involved
Administrators What are your pain points What would you add to this list
Concerns raised by Administrators
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
The information on the roadmap and future software development efforts are intended to outline general product direction and should not be relied on in making a purchasing decision
It is important to establish policies that ensure that the often-conflicting needs of administrators developers and end-users are met in a balanced way appropriate for your environment
In this session we will discuss the commonly reported pain points and outline the types of policies and procedures that that can help bring harmony
Be prepared to discuss your own experiences
Introduction
bull Administrators of Pipeline Pilot servers wish to have a controlled environment to ensure that ownership and access is properly identified and enforced
bull Protocol developers desire the ability to quickly easily publish protocols and updates for personal and production use
bull End-users need deployed applications to be accessible tested and maintained
Overview
End Users interact via interfaces like Web Port
bull Frustrated when process to gain access is difficult
bull When impersonation is on user-specific resource access issues can arise
bull Access to network resources user folders etc
bull Who to call if the published protocol breaks
bull Performance issues when server is not properly sized
Concerns raised by End-Users
Developers interact via the Professional Client
bull Issues with testing and deployment without a separate Development Server
bull Lack of uniform access to key resources across Development and Production (ODBCJDBC 3rd party tools disk paths etc)
bull Lack of consistent XMLDB folder structure between Development and Production servers make deployment unnecessarily difficult
bull Access to a defined location for storing shared reports particularly interactive reports which are best hosted on the Pipeline Pilot server
bull Frustrated by imposed policies that require extra effort or approval for protocol publication
Developers What would you like to add
Concerns raised by Developers
bull Lack of defined production protocol publication approval process makes it hard to get sign-off for upgrades and changes
bull When published protocols lack documentation and a defined owner the admin doesnrsquot know who to turn to when a user reports an error
bull Lack of distinction between Development and Production servers
bull Lack of coordination when multiple servers are involved
Administrators What are your pain points What would you add to this list
Concerns raised by Administrators
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
It is important to establish policies that ensure that the often-conflicting needs of administrators developers and end-users are met in a balanced way appropriate for your environment
In this session we will discuss the commonly reported pain points and outline the types of policies and procedures that that can help bring harmony
Be prepared to discuss your own experiences
Introduction
bull Administrators of Pipeline Pilot servers wish to have a controlled environment to ensure that ownership and access is properly identified and enforced
bull Protocol developers desire the ability to quickly easily publish protocols and updates for personal and production use
bull End-users need deployed applications to be accessible tested and maintained
Overview
End Users interact via interfaces like Web Port
bull Frustrated when process to gain access is difficult
bull When impersonation is on user-specific resource access issues can arise
bull Access to network resources user folders etc
bull Who to call if the published protocol breaks
bull Performance issues when server is not properly sized
Concerns raised by End-Users
Developers interact via the Professional Client
bull Issues with testing and deployment without a separate Development Server
bull Lack of uniform access to key resources across Development and Production (ODBCJDBC 3rd party tools disk paths etc)
bull Lack of consistent XMLDB folder structure between Development and Production servers make deployment unnecessarily difficult
bull Access to a defined location for storing shared reports particularly interactive reports which are best hosted on the Pipeline Pilot server
bull Frustrated by imposed policies that require extra effort or approval for protocol publication
Developers What would you like to add
Concerns raised by Developers
bull Lack of defined production protocol publication approval process makes it hard to get sign-off for upgrades and changes
bull When published protocols lack documentation and a defined owner the admin doesnrsquot know who to turn to when a user reports an error
bull Lack of distinction between Development and Production servers
bull Lack of coordination when multiple servers are involved
Administrators What are your pain points What would you add to this list
Concerns raised by Administrators
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
bull Administrators of Pipeline Pilot servers wish to have a controlled environment to ensure that ownership and access is properly identified and enforced
bull Protocol developers desire the ability to quickly easily publish protocols and updates for personal and production use
bull End-users need deployed applications to be accessible tested and maintained
Overview
End Users interact via interfaces like Web Port
bull Frustrated when process to gain access is difficult
bull When impersonation is on user-specific resource access issues can arise
bull Access to network resources user folders etc
bull Who to call if the published protocol breaks
bull Performance issues when server is not properly sized
Concerns raised by End-Users
Developers interact via the Professional Client
bull Issues with testing and deployment without a separate Development Server
bull Lack of uniform access to key resources across Development and Production (ODBCJDBC 3rd party tools disk paths etc)
bull Lack of consistent XMLDB folder structure between Development and Production servers make deployment unnecessarily difficult
bull Access to a defined location for storing shared reports particularly interactive reports which are best hosted on the Pipeline Pilot server
bull Frustrated by imposed policies that require extra effort or approval for protocol publication
Developers What would you like to add
Concerns raised by Developers
bull Lack of defined production protocol publication approval process makes it hard to get sign-off for upgrades and changes
bull When published protocols lack documentation and a defined owner the admin doesnrsquot know who to turn to when a user reports an error
bull Lack of distinction between Development and Production servers
bull Lack of coordination when multiple servers are involved
Administrators What are your pain points What would you add to this list
Concerns raised by Administrators
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
End Users interact via interfaces like Web Port
bull Frustrated when process to gain access is difficult
bull When impersonation is on user-specific resource access issues can arise
bull Access to network resources user folders etc
bull Who to call if the published protocol breaks
bull Performance issues when server is not properly sized
Concerns raised by End-Users
Developers interact via the Professional Client
bull Issues with testing and deployment without a separate Development Server
bull Lack of uniform access to key resources across Development and Production (ODBCJDBC 3rd party tools disk paths etc)
bull Lack of consistent XMLDB folder structure between Development and Production servers make deployment unnecessarily difficult
bull Access to a defined location for storing shared reports particularly interactive reports which are best hosted on the Pipeline Pilot server
bull Frustrated by imposed policies that require extra effort or approval for protocol publication
Developers What would you like to add
Concerns raised by Developers
bull Lack of defined production protocol publication approval process makes it hard to get sign-off for upgrades and changes
bull When published protocols lack documentation and a defined owner the admin doesnrsquot know who to turn to when a user reports an error
bull Lack of distinction between Development and Production servers
bull Lack of coordination when multiple servers are involved
Administrators What are your pain points What would you add to this list
Concerns raised by Administrators
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
bull Frustrated when process to gain access is difficult
bull When impersonation is on user-specific resource access issues can arise
bull Access to network resources user folders etc
bull Who to call if the published protocol breaks
bull Performance issues when server is not properly sized
Concerns raised by End-Users
Developers interact via the Professional Client
bull Issues with testing and deployment without a separate Development Server
bull Lack of uniform access to key resources across Development and Production (ODBCJDBC 3rd party tools disk paths etc)
bull Lack of consistent XMLDB folder structure between Development and Production servers make deployment unnecessarily difficult
bull Access to a defined location for storing shared reports particularly interactive reports which are best hosted on the Pipeline Pilot server
bull Frustrated by imposed policies that require extra effort or approval for protocol publication
Developers What would you like to add
Concerns raised by Developers
bull Lack of defined production protocol publication approval process makes it hard to get sign-off for upgrades and changes
bull When published protocols lack documentation and a defined owner the admin doesnrsquot know who to turn to when a user reports an error
bull Lack of distinction between Development and Production servers
bull Lack of coordination when multiple servers are involved
Administrators What are your pain points What would you add to this list
Concerns raised by Administrators
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Developers interact via the Professional Client
bull Issues with testing and deployment without a separate Development Server
bull Lack of uniform access to key resources across Development and Production (ODBCJDBC 3rd party tools disk paths etc)
bull Lack of consistent XMLDB folder structure between Development and Production servers make deployment unnecessarily difficult
bull Access to a defined location for storing shared reports particularly interactive reports which are best hosted on the Pipeline Pilot server
bull Frustrated by imposed policies that require extra effort or approval for protocol publication
Developers What would you like to add
Concerns raised by Developers
bull Lack of defined production protocol publication approval process makes it hard to get sign-off for upgrades and changes
bull When published protocols lack documentation and a defined owner the admin doesnrsquot know who to turn to when a user reports an error
bull Lack of distinction between Development and Production servers
bull Lack of coordination when multiple servers are involved
Administrators What are your pain points What would you add to this list
Concerns raised by Administrators
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
bull Issues with testing and deployment without a separate Development Server
bull Lack of uniform access to key resources across Development and Production (ODBCJDBC 3rd party tools disk paths etc)
bull Lack of consistent XMLDB folder structure between Development and Production servers make deployment unnecessarily difficult
bull Access to a defined location for storing shared reports particularly interactive reports which are best hosted on the Pipeline Pilot server
bull Frustrated by imposed policies that require extra effort or approval for protocol publication
Developers What would you like to add
Concerns raised by Developers
bull Lack of defined production protocol publication approval process makes it hard to get sign-off for upgrades and changes
bull When published protocols lack documentation and a defined owner the admin doesnrsquot know who to turn to when a user reports an error
bull Lack of distinction between Development and Production servers
bull Lack of coordination when multiple servers are involved
Administrators What are your pain points What would you add to this list
Concerns raised by Administrators
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
bull Lack of defined production protocol publication approval process makes it hard to get sign-off for upgrades and changes
bull When published protocols lack documentation and a defined owner the admin doesnrsquot know who to turn to when a user reports an error
bull Lack of distinction between Development and Production servers
bull Lack of coordination when multiple servers are involved
Administrators What are your pain points What would you add to this list
Concerns raised by Administrators
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Key Folders
bull $(UserDir) default location ltinstallgtpublicusers
bull $(JobDir) default location ltinstallgt webjobs Alias $(RunDirectory)
bull ltinstallgtxmldbComponents and ltinstallgtxmldbProtocols
bull ltinstallgtapps
bull ltinstallgtwebapps This folder is pointed to by the webapps alias that maps files in ltinstallgtwebappsmyapp to URLs in the form httphostnameportwebappsmyapp
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Key Resources and Dependencies
bull Data sources
bull ODBC and JDBC drivers
bull Database connections
bull Third-Party Applications
bull Web services
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Areas where policies should be considered Part 1
bull Production publication rights
bull Which protocols require official packaging and regressions
bull Roles (Permissions ATS4-PLAT02)
bull Folder structure for Protocols and ProtocolsWeb Services
bull Protocol ownership and responsibilities for documentation fixes and validation
bull Differentiating DEV and PROD environments
bull Testing requirements for upgrades and migrations
bull Management of dependant resources
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Areas where policies should be considered Part 2
bull Results management
bull Number of protocol versions to keep
bull Data longevity and size
bull Management of scheduled tasks
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Security and location considerations
bull Authentication type bull Impersonation or not bull Unrestricted File BrowsingEditing bull Location of User Jobs andor XMLDB folders bull XMLDB Access Rights bull Automatic validation bull Apache service account bull Anonymous Access configuration bull Define ODBCJDBC connections and access rights bull Third-party tool server installation (R etc)
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Policies Protocol Publication
bull Who may publish protocols to production servers bull Will you limit access by Project By Folder bull What documentation regression or testing requirements
should be followed bull Will access rights differ for Productions vs UAT servers bull What defined ROLES and ACCESS RIGHTS should be
implemented (ATS4-PLAT02) bull Consider custom validation requirements for publication to
production
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Best Practices Admin
bull Host separate installations for Dev Prod and Apps
bull Ensure all servers have equal setup in regards to folder structure and dependencies Any developed protocol that makes use of a system resource should have equal access to that system resource from every server where it is developed or deployed For example all servers should have the same databases configured
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Best Practices Protocol publication
bull For standard publication to Web Port interactive forms and scheduled tasks the best practice is moderate controls with defined ownership and documentation
bull Regressions or manual test plans are encouraged for published production protocols
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Best Practices Developers
bull Develop regression tests to automatically re-validate published production protocols before and after server deployments migration or software upgrades
(ATS2-05) Pipeline Pilot 85 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol Development for Developers
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Best Practices Developers
Label protocols with the original author and validation procedures preferably in the help text
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Best Practice Result publication
bull For shared short-term access writing to the $(jobdir) is a good choice but the result will
only be available until the job is cleaned up bull For longer-term access manage the results by writing them to a location you control and
commit to a folder or naming structure that denotes ownership so that the owner can be asked to remove when no longer required
bull In Pipeline Pilot 85 and earlier the preferred location to write results for which you wish to share a URL for long-term access is into the path $(SciTegicRoot)webapps on your Pipeline Pilot server An alias on the Pipeline Pilot Apache Web server named webapps points to this webapps directory and you can easily create and reference subfolders to help keep your files organized To give a specific example an HTML page written to $(SciTegicRoot)webappsmyReportreport1html can be accessed by all users at a URL like httpltservernamegtltportgtwebappsmyReportreport1html
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Data longevity and size
bull When a protocol is run a job folder is created and has a defined lifetime depending on the invoking client (httpscommunityaccelryscomdocsDOC-3623 )
bull Since interfaces like Web Port do not do explicit automatic job folder cleanup some sites institute regular job folder cleanup as a scheduled task and notify their users of this policy
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip
Support
bull We pride ourselves on our excellent support
ndash Reach us by email at supportaccelryscom
ndash Call the support hotline
ndash Take advantage of the Accelrys Community bull No login is required to read the forums
bull Logging in to your Accelrys Community account gives you access to the Support Center where you can access the software download center and documentation libraries From here you can also access change request widgets the Pipeline Pilot product documentation post to the forums etchellip