Administrators of Pipeline Pilot servers wish to have a controlled environment to ensure that ownership and access is properly identified and enforced. Protocol developers desire the ability to quickly easily publish protocols and updates for production use. End-users need deployed applications to be tested and maintained. It is important to establish policies that ensure that these often-conflicting needs 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!

1. (ATS4-PLAT03) Balancing Security
with access for Development
Lynn Miller
Principal Technical Support Scientist
Lynn.Miller@accelrys.com

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

3. Introduction
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!

4. Overview
• Administrators of Pipeline Pilot servers wish to have a
controlled environment to ensure that ownership and
access is properly identified and enforced.
• Protocol developers desire the ability to quickly easily
publish protocols and updates for personal and
production use.
• End-users need deployed applications to be accessible,
tested and maintained.

5. End Users interact via interfaces like Web Port

6. Concerns raised by End-Users
• Frustrated when process to gain access is difficult
• When impersonation is on, user-specific resource access issues can
arise.
• Access to network resources, user folders, etc
• Who to call if the published protocol breaks?
• Performance issues when server is not properly sized.

7. Developers interact via the Professional Client

8. Concerns raised by Developers
• Issues with testing and deployment without a separate Development
Server
• Lack of uniform access to key resources across Development and
Production. (ODBC/JDBC, 3rd party tools, disk paths, etc)
• Lack of consistent XMLDB folder structure between Development and
Production servers make deployment unnecessarily difficult.
• Access to a defined location for storing shared reports, particularly
interactive reports which are best hosted on the Pipeline Pilot server.
• Frustrated by imposed policies that require extra effort or approval for
protocol publication
Developers: What would you like to add?

9. Concerns raised by Administrators
• Lack of defined production protocol publication approval process
makes it hard to get sign-off for upgrades and changes.
• When published protocols lack documentation and a defined
owner the admin doesn’t know who to turn to when a user reports
an error.
• Lack of distinction between Development and Production servers.
• Lack of coordination when multiple servers are involved
Administrators: What are your pain points? What would you add to this list?

10. Key Folders
• $(UserDir) default location <install>/public/users
• $(JobDir) default location <install>/ web/jobs. Alias
$(RunDirectory)
• <install>/xmldb/Components; and
<install>/xmldb/Protocols
• <install>/apps
• <install>/web/apps This folder is pointed to by the webapps
alias that maps files in <install>/web/apps/myapp to URLs in
the form http://hostname:port/webapps/myapp

11. Key Resources and Dependencies
• Data sources
• ODBC and JDBC drivers
• Database connections
• Third-Party Applications
• Web services

12. Areas where policies should be considered: Part 1
• Production publication rights
• Which protocols require official packaging and regressions
• Roles (Permissions ATS4-PLAT02)
• Folder structure for Protocols and Protocols/Web Services
• Protocol ownership and responsibilities for documentation,
fixes and validation
• Differentiating DEV and PROD environments
• Testing requirements for upgrades and migrations
• Management of dependant resources

13. Areas where policies should be considered: Part 2
• Results management
• Number of protocol versions to keep
• Data longevity and size
• Management of scheduled tasks

14. Security and location considerations
• Authentication type
• Impersonation or not
• Unrestricted File Browsing/Editing
• Location of User, Jobs and/or XMLDB folders
• XMLDB Access Rights
• Automatic validation
• Apache service account
• Anonymous Access configuration
• Define ODBC/JDBC connections and access rights
• Third-party tool server installation (R, etc)

15. Policies: Protocol Publication
• Who may publish protocols to production servers?
• Will you limit access by Project? By Folder?
• What documentation, regression or testing requirements
should be followed?
• Will access rights differ for Productions vs UAT servers?
• What defined ROLES and ACCESS RIGHTS should be
implemented? (ATS4-PLAT02)
• Consider custom validation requirements for publication to
production

16. Best Practices: Admin
• Host separate installations for Dev, Prod and Apps
• 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.

17. Best Practices: Protocol publication
• For standard publication to Web Port,
interactive forms and scheduled tasks, the
best practice is moderate controls with
defined ownership and documentation.
• Regressions or manual test plans are
encouraged for published production
protocols.

18. Best Practices: Developers
• Develop regression tests to automatically re-validate
published production protocols before and after server
deployments, migration or software upgrades
(ATS2-05) Pipeline Pilot 8.5 for IT Pros
(ATS2-15) Introduction to Pipeline Pilot Protocol
Development for Developers

19. Best Practices: Developers
Label protocols with the original author and validation
procedures, preferably in the help text

20. Best Practice: Result publication
• 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.
• 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.
• In Pipeline Pilot 8.5 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)/../web/apps on your
Pipeline Pilot server. An alias on the Pipeline Pilot Apache Web server named "webapps"
points to this web/apps 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)/../web/apps/myReport/report1.html can be accessed by all users at a
URL like http://<servername>:<port>/webapps/myReport/report1.html

21. Data longevity and size
• When a protocol is run a job folder is created, and has a
defined lifetime depending on the invoking client.
(https://community.accelrys.com/docs/DOC-3623 )
• 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.

22. Support
• We pride ourselves on our excellent support!
– Reach us by email at support@accelrys.com
– Call the support hotline
– Take advantage of the Accelrys Community
• No login is required to read the forums.
• 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,
etc….