Lombardi Admin Training Notes 16dec2008
Objectives
- Tech overview
- Installaton
- configuration
- user management
Tech Overview
- All configuration done in the process database as metadata (including workflows and processes, they are stored as xml in the process database)
- users all access the data via coaches that are configured using metadata in the process database
- no version control (coming in teamworks 7)
- might consider using a teamworks library folder for version control
- export and import in order to migrate settings from one environment to another.
Teamworks installation overview
Two JVM's
1) Process Server
2) Performance Server (more of a reporting server, it does not improve performance)
- They can be on separate boxes (and should be to improve performance) and they must use separate databases
- They must use separate databases, and you can put the databases on separate servers. In fact, you must create 2 databases before install for lombardi to install into.
- we do get access to the performance server tables (still need to find out how). the transactional database (process server) stores all the data as blobs, so treat it as a black box that we dont want to access directly.
System of Record
- Lombardi should not be the system of record (not be the final application data that is being approved through the workflow)
- before a process ends, it should write its data to another data/archive database that tracks the data being approved/worked on.
UI Layer
- sits on top of the process servers
- UI choices
- Authoring Environment (teamworks client)
- Server consoles
- Process Portal
- Teamworks for Office (infopath forms)
- Teamworks for SharePoint (webparts?)
Frameworks (defined at the app server level, not teamworks itself)
- Connector Framework (integration framework)
- used to integrate to an external database (wrapping service)
- Connectors were used in the last class for process modeling
- all teamworks javascript code, all included in the default install
- can publish web services (SOAP) for external access
- Messaging Framework
- teamworks uses a JMS Message Queue, and only allows one. Its called the "Teamworks event Manager"
- you can use SOAP, HTTP or JMS
- teamworks breaks it all down to JMS.
- can only send messages in (one way communications to teamworks)
- to listen to another message queue, you can write a services to poll the external message queue, you can use a UCA (undercover agent) wrapper to do polling.
- Security Framework
- (we will come back to this tomorrow, I think)
Process Server
- Made up of 3 engines
- BPD Engine
- at the start event of a process, a new instance of that BPD (class) is initialized, variables are initialized
- calls services. Passes variables to services and catches return variables
- Even Manager
- JMS Message Queue
- acts as a scheduler
- UCA's are teamworks' way of setting up a sechedule in this event manager
- UCA service wrapper = Event Definition (determines when it runs)
- service = Event Handler (executes the event)
- can call extermally via HTTP, SOAP or JMS (authentication and authorization not used here, knowing the URL and message format gives you access)
- you have to send messages to teamworks, it cant listen to another queue by default
- Service Engine
- when service is called by a BPD instance and its start event is encountered, that service is initialized for that instance of the BPD and variables are initialized by the service.
- catches variables from the BPD, returns variables back to the BPD call
- When major changes are made to a BPD or a service who has in-flight transactions, you need to somehow account for that. If you, for example, add required variables to a BPD and in-flight transactions might not have them defined, you must either create a new BPD or add a check point in to "fix" old records before the error occurs.
Performance Server
- You can enable/disable the performance server
- Process server sends definitions to the performance server (via JMS)
- new definitions are created as tables in the performance server database.
- when the state of the BPD changes, its tracked in a local table on the process server. On a regular basis, that data is sent to the performance server and cleared from the process server.
- if you enable autotracking, you should enable the performance server so that it clears out the local process server tracking table.
Server Installation
- no registry entries. Everything is installed in the teamworks folder. Shooting for a pure J2EE server/install environment.
- choose teamworks management products
- you can choose what products to install. If you break up the servers onto multiple boxes, be sure to install the process server first. Install the performance server last and point it to an existing process server.
- Pick the application server
- jboss is installed with teamworks, if you pick another app server, you must have it already installed)
- process server options
- multicast address - jboss is clustering for the multicast address. you can turn this off if you are not doing jboss clustering later after the install
- UCA Error Failure notification - you can change this user after the install
- performance server options
- again, make the multicast unique for the performance server cluster, which can be disabled later.
- Process Server Database
- databases must have been created in advance
- install folder
- use a name with the version number. You can have multiple versions on the same box.
- in my examples, I'm using "c:\teamworks61bsr"
- choose shortcut folder
- in my examples, I installed shortcuts in the teamworks folder on my desktop
- finish install wizard
Post Install Configuration
- Run database install scripts for the process server
- open a command propt and change directory to c:\teamworks61bsr\process-server\db\
- run "DBSLoad mssql"
- run "DBSpload mssql" next
- run "DBLoad mssql" last
- Run database scripts for performance server
- run "DBSLoad mssql"
- run "DBLoad mssql"
- log4j is not set to start by default. You can ignore that.
- Run authoring client and connect to the process server.
- login as user "tw_admin" with password "tw_admin" (this is the default from an OOtB install)
- if this is the first time running eclipse, you will be prompted to accept the default working directory. Check "use this as default" and click "ok" to accept.
- Close the welcome screen by clicking the x in the tab to see the default teamworks library view, or click "go to workbench". You should see an environment similar to the screenshot below.
- now we will import the default system library
- import "C:\Teamworks61bsr\imports\TWSystemData.zip". This imports all the base variable types, connectors, etc that you need to start creating new BPD's
- the import will create a new system library from the root.
- you should never modify the system library, it is maintained by lombiardi and could be changed by system upgrades.
- now we can setup the client for other developers to use to connect to the server.
- the client does not need to be installed, just copied the directories "C:\Teamworks61bsr\ae-eclipse" and "C:\Teamworks61bsr\java", so long as they drop it in the same folder path.
- in the eclipse.ini file you can change the default configuration of the client. You can force it to connect to any server you want in this config file.
- on the end user machine, the path must be the same as the one you used from your server install. For example, in this case everyone must copy Teamworks61bsr to c:\Teamworks61bsr on their local machine.
Validate Install (notes from the handout)
- Database
- Authoring Environment
- Web Application
- validate you can hit the following site (login as tw_admin when necessary)
- http://<host>:8081/ - for the jboss admin page
- http://<host>:8081/teamworks/ - for the teamworks admin
- http://<host>:8081/portal/ - for the teamworks portal site
- Logging
- Error Log
Add custom classpaths and set custom JVM settings, if necessary
- you can customize these settings for the process server and performance server separately.
- C:\Teamworks61bsr\process-server\startup\wrapper.conf for the process server and C:\Teamworks61bsr\performance-server\startup\wrapper.conf for the performance server
- you can change/add classpaths in this file
- Lombardi recommends setting the max/min memory to 1gig (1024 meg). The max must at least match the min, cant be less.
- under NT services, you can change the service name/information to match this version of the install simply for readability
- if you changed a config in this file, you should restart the service for the changes to take effect.
- Since 2 JVM's will be running, if you want to tell them appart, you can do that by copying the java.exe for each JVM that should run: tw61_process_java.exe and tw61_performance_java.exe in the folder "C:\Teamworks61bsr\java\bin". Update the first line of the wraper.conf file to use the java exe that matches (without the .exe extension) then restart the service.
Install as a Service
- run C:\Teamworks61bsr\process-server\installProcessServerService.cmd to install the service. The verstion name can be changed in the config file mentioned above ( C:\Teamworks61bsr\process-server\startup\wrapper.conf )
- check to see that the service is now listed in the services applet.
- make sure to close your command prompt running the service, if its currently running. Then try starting the NT service and connecting via the authoring client.