How you can use the Brio.Portal Java API without

Download Report

Transcript How you can use the Brio.Portal Java API without

How you can use the
Brio.Portal Java API without
learning Java
Nathan Stratton Treadway
Ray Ontko & Co.
[email protected]
Insight 2000
Wednesday, May 16, 1:00 PM
Session Overview
• Introduction to SPECT
• Comparisons
•
•
•
•
•
•
•
•
ONE/Administrator Tool
ONE/Script
SPECT
Custom Java Applications
Example Implementations
Downloading and Installing
Limitations
Possible Future Features
Introduction to SPECT
• Brio.Portal implementations involve:
•
•
configuration of users, groups, categories,
etc.
loading of reports
• These can be done manually using
ONE/Administrator
• Can also be done in a custom Java
program using ONE/API
• SPECT is designed to fit in the middle
ground between these two options
Introduction (continued)
• SPECT: Simple Portal-Enhancing
Configuration Tool
• Written in Java against ONE/API, but
designed to be usable without Java
programming
• Can be customized if needed
•
source released under GNU Public
License
• Controlled by standard text files
•
•
can be created using a text editor to
automate basic tasks
can be generated by some other program
to automate more complex tasks
•
e.g. security feeds from other systems
Introduction: Examples
Example control file commands:
create user TestUser password=welcome
description="Test User" ;
update user TestUser
email="[email protected]";
update category "/Demo/Private"
group=Employee
permissions=700;
delete file "/Demo/Private/Demo.doc";
ONE/Administrator Tool
• Graphical environment (GUI)
• Cannot be automated
• Can do almost anything possible within
Brio.Portal
• Communicates directly with Portal
Services
ONE/Script
• Also based on ONE/APl
• support for simple scripting language
•
•
•
looping, conditional execution
variables, integer math
reading/writing of arbitrary files
• very limited options for error handling:
•
•
errors can be ignored, or
errors can cause script to abort
• some options available in the ONE/API
may not (yet) be supported in
ONE/Script
•
e.g. setting of e-mail addresses in
Brio.Portal v6.0
SPECT
• Not a scripting language
•
no looping commands, variables, etc.
• Designed to be easy to control using
files generated by other programs
•
•
e.g. SQR programs that read configuration
information from a database
these other programs encode the
"business logic" for the implementation
• Currently supports many operations
that are performed repeatedly in a
typical Portal environment
•
•
create/update/delete of users, categories,
groups, and files
assigning user-group membership
SPECT (continued)
• "Installation" or "one-time" tasks are
not supported
•
e.g. configuration of Services, definition of
Hosts and Databases
• In general, SPECT allows access to all
options provided in ONE/API on
supported actions.
• Error handling flexibility
•
•
Actions that cause errors can be written to
a "bad record" file for later review.
Processing on rest of control file continues
unaffected.
Custom Java Application
• Heavy initial effort needed up-front in
implementation effort
• Extensive Java skills needed to write a
robust application from scratch
• Application can be completely
customized for the specific
environment
•
Business logic can be integrated tightly
with Brio.Portal Repository contents
• Application can use any ONE/API
feature (but may sometimes have to
be modified when Portal is upgraded)
Example: PSoft Security Tree
• Situation
•
•
Client was maintaining access security in
a custom PS Security Tree added to PS
Financials
Portal security needed to reflect the tree
• Solution
•
SQR program reads security tree
tables/views and applies business logic to
determine:
•
•
•
•
Groups, Users, Categories
group memberships
SPECT control file is written
SQR program invokes SPECT
automatically to perform the load
Example: PSoft Security Tree
# (Sample PS Security Tree
# Interface SPECT file)
SETCONFIG WHEN-PREEXISTS=UPDATE;
# Groups
create group DEPTAA;
# Users
create user JDOE
description="John Doe"
password = "700600"
group = JDOE
home-category="/Project Expense Reports"
email="[email protected]"
permissions=740
execute-jobs=false;
Example: PSoft Security Tree
# (Sample PS Security Tree Interface
# SPECT file, continued )
# Categories
create category
"/Project Expense Reports/DEPTAA"
owner=administrator
group=DEPTAA
permissions=740
;
# User_Groups (security)
add usergroups "JDOE"
groups=
"PROJECT_EXPENSE_RPTS,DEPTAA,DEPTAAS1,DEPT
AAS2";
Example: Mainframe Reports
• Situation
•
A large number of reports being generated
on a mainframe and then sent to Portal for
publishing
•
Configuration info stored in Oracle table
and maintained by hand
•
category to hold report
•
keywords to be associated with report
•
who can view it
•
expiration period
Example: Mainframe Reports
• Solution
•
SQR "load manager" program reads
config table for each report in input
directory
•
Originally, generated a data file read by a
ONE/Script script
•
•
because of error handling limitations, SQR had
to call the script repeatedly until all files were
successfully loaded
Now, SQR calls SPECT once and uses
"bad record" feature to keep track of which
reports failed to load
Example: Mainframe Reports
SETCONFIG
BAD-FILE=/reportmart/stage/spect_bad_23080;
SETCONFIG
GOOD-FILE=/reportmart/stage/spect_good_23080;
SETCONFIG WHEN-MULTIPLE-PREEXISTS=ADD;
CREATE FILE
"/Common_Rpts/Daily/Archive/RPT22_20000424.pdf"
filespec=
"/reportmart/stage/RPT22_20000424.pdf"
description="Sales Report by Region"
mime-type=application/pdf
group=ABC_CO
permissions=740
expiration=+30
keywords="PRINTED,REGION,SALES,TOTALS" ;
Downloading and Installing
• SPECT is available from the Ray
Ontko & Co. Brio.Portal Library
•
http://www.ontko.com/portal/
• You will download the proper .tgz or
.zip file
• Installation instructions also found here
• You must have ONE/API installed on
the machine where you will be running
SPECT
• To edit/recompile SPECT, you will also
need a Java development environment
for your platform
•
SPECT should work if you can compile
and run the ONE/API sample programs
Limitations
• SPECT doesn't support "two-way"
interaction with the Repository
•
"business rules" logic must be
independent of the Repository
• Not a scripting language
•
in many cases, a new control file must be
generated each time SPECT is invoked
• Dependent on ONE/API interface
Possible Future Features
• Support for
•
Loading of dynamic jobs
•
Manipulation of links
•
Moving objects between categories
•
Manipulation of specific versions of a file
object
• Operations to be performed on input
files during report loading
•
•
rename or delete input file
based on success and/or failure of load
• Accept control file from standard input
• Allow listing/display of info about
objects in the Repository