(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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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