Download - Lansa Development V12
LANSA AdministrationAdministration of LANSA Development
Development Environments
Task Tracking
Repository Synchronization
Development Flow with Task Tracking
Administration of LANSA Deployments
IBM i Only
Windows Clients w/ IBM i Server
Windows Clients w/ Windows Server
Windows Clients w/ Unix Server
1
Administration of LANSA Development
Development Environments
DEV – Development Environment
Use Task Oriented Task Tracking
Use Repository Synchronization
All development is done in this Environment
TST –Testing Environment
Updated via exports by task from DEV
No changes allowed in this environment
Compiles for “Level Checks” on IBM i
2
Administration of LANSA Development
Development Environments
RLS – Staged for Release (optional)
Updated via exports by task from DEV
No Changes allowed in this environment
Compiles for “Level Checks” on IBM i
PRD – Production
Update via exports by task from DEV
No Changes allowed except in emergency
Compiles for “Level Checks” on IBM i
3
Administration for Development
All development with detailed task tracking
Environment for QA after programmer tests
Optional, staging for deployment
Production or current release for ISVs
4
Development
Test
Ready to Deploy
Production
Administration of LANSA Development
Development Environments
Each partition should be separate LANSA installation
Allow for change & testing of LANSA system wide options or objects
Insures that all necessary objects are sent from one system to another
Allow for LANSA upgrades to be tested prior to deployment to development or production
5
Administration of LANSA Development
Development Environments
IBM i Master System Windows Client Slave Systems Database on Each Client
Development utilizes Check-in & Check out
Repository Synchronization keeps Windows Clients in sync
Windows Server Slave System Development utilizes Check-in & Check out No Repository Synchronization Required
Use LANSA Network Clients for local developers Requires license on each Client PC or server license
Citrix/Terminal Server Clients for remote developers Requires license on Windows Server or server license
6
Administration of LANSA Development
Development Environments
Windows Master System Network Client Installation for local developers
Requires license on each Client PC or Server license
Citrix/Terminal Server Clients for remote developers Requires license on Windows Server or server license
Utilize “deliver to” capability to move software to IBM i or Linux
Utilize deployment tool to move software to Windows Servers
Stand-alone Windows Master Provides for single user local development on Client PC
Requires license on theClient PC or Server license
Utilize “deliver to” capability to move software to IBM i or Linux
Utilize deployment tool to move software to Windows Servers
7
Administration of LANSA Development
Methods of Task Tracking
Reminder Based Task Tracking
Product / Developer / Minimum
User must manually manage changes
Task-oriented Task Tracking
Provides control over development
Provides control over developers
System manages changes
Instills discipline in development process
8
Administration of LANSA Development
Task Oriented Task Tracking
Each new feature you are adding should be tracked separately –- WHY?
Highly recommend a task for the database changes separate from the new feature –- WHY?
Setup of task(s) could be done with the specification of the requirement
Manage task conflicts manually as exceptions occur
9
Task Oriented Task Tracking
Configure task tracking: YES / YES / NO / NO / YES or NO
Parameter 1 = Task Tracking Active
Parameter 2 = Work Requires Task Yes – User must be signed on with task
No –Tasked assigned after work via pop-up
Parameter 3 = Prompt Confirm/Change Task Allows developers to change Task assigned to object as desired
Parameter 4 = Task Changes To Match Object being maintained Automatically changes Task assigned to object
Parameter 5 = Disable Special Security on Tasks Yes = Normal menu security controls access
No = Must be QSECOFR or Partition Security Officer to work with tasks
10
Task Oriented Task TrackingDetails of Task Oriented Task Tracking
1. Entered tasks are set to OPN
Pre-setup or set-up as needed
2. Set task to WRK when developer begins work
Specific developer can be assigned or use standard group profile (control)
3. Set task to CLS when developer is done testing
Developer believes the change is complete
4. Export task to TST environment Make a uniquely named export list for each task
Retain the export list & save file / package
11
Administrationof Task Oriented Task Tracking
Details of Task Oriented Task Tracking (cont)
5. Reset task to WRK for developer rework Developer does rework in development environment
Re-export using same save file and task id
6. Repeat steps 3-5 until QA is approved
7. Set Task to FIN (Finished) Releases Objects from Task Lock
8. Import task export list to RFD
9. Import task(s) export list(s) to PRD when ready to deploy into production. Tasks must be exported in sequence of completion
12
Tip and Simple ProjectCreate a simple system to track your changes
Files Request Master
ID - Via autonum {Becomes task ID}
Status (Requested, Approved, Working, QA, Finished, In production) {May be a table}
Requester {May be a table}
Dates (requested, assigned,QA, Production)
Short Description
Request Detail
ID Sequence Number
Long Description
13
Tip and Simple Project
Create a simple system to track your changes
Simple Header and Detail Program(s)
Good first VLF or CRUD Wizard application
(Use the VL Framework or CRUD Wizard)
14
Repository Synchronization
Windows Client Development with IBM i Master Repository (Only)
Allows for automatic propagation from IBM i to non-iSeries repositories
Via Host Monitor
New Action 33 on IBM i allows changes made on IBM i to be propagated
*ALL is Valid
Used for Group based development
Requires Discipline to make it work
15
Repository Synchronization Benefits
Keeps all development PCs in sync
Allow you to keep a test PC in sync
Be Careful Will load checked-in objects even if they are not working can make testing difficult
It will load all changes before it allows you to check-in It may take time to simply check in a single change you have made
Remote developers may have long waits while connecting
16
Administration for DevelopmentDeployment Options
IBM i Server w/ 5250 Clients
IBM i Server w/ Windows Rich Clients
IBM i w/ Browser based clients
Windows Server w/ Windows Rich Clients
Windows Server w/ Browser based clients
VL for Linux (Red Hat or SuSE) no character base Unix Solution
Linux Server with Browser based clients
Linux Server w/ Windows Clients
17
Deployment Options
IBM i Export / Import High Speed Export / Import Deliver toWindows Deployment Tool Templates Server Objects Client Objects (Thick vs. Thin) JIT
Linux Deliver to
18
Sample Programs for Moving Data From IBM i to Windows
19
FUNCTION OPTIONS(*DIRECT)
*
DEFINE FIELD(#W_PASSWD) TYPE(*CHAR) LENGTH(10) LABEL('Password') INPUT_ATR(ND)
DEFINE FIELD(#W_RTNCDE) TYPE(*CHAR) LENGTH(2) LABEL('Return Code')
DEFINE FIELD(#W_SRVNAME) TYPE(*CHAR) LENGTH(10) LABEL('Target Sys Name')
DEFINE FIELD(#W_CALLFUN) TYPE(*CHAR) LENGTH(10) LABEL('Calling Func')
*
REQUEST FIELDS(#USER #W_PASSWD #W_SRVNAME #W_CALLFUN)
*
USE BUILTIN(DEFINE_OS_400_SERVER) WITH_ARGS(AS400SRV #W_SRVNAME N)
TO_GET(#W_RTNCDE)
USE BUILTIN(CONNECT_SERVER) WITH_ARGS(AS400SRV #W_PASSWD)
TO_GET(#W_RTNCDE)
* Define and connect Other server here, if destination
* system is not local DB
* Function calls to access to server files
CALL PROCESS(*DIRECT) FUNCTION(#W_CALLFUN) EXIT_USED(*NEXT)
MENU_USED(*NEXT)
USE BUILTIN(DISCONNECT_SERVER) WITH_ARGS(AS400SRV) TO_GET(#W_RTNCDE)
* Disconnect Other server here
Sample Programs for Moving Data From IBM i to Windows
20
FUNCTION OPTIONS(*DIRECT)
* Define work fields
* Delete local data if there is any
SELECT FIELDS(*ALL) FROM_FILE(FILEA)
DELETE FROM_FILE(FILEA)
ENDSELECT
* Connect file - for the first record
USE BUILTIN(CONNECT_FILE) WITH_ARGS(FILEA AS400SRV)
SELECT FIELDS(*ALL) FROM_FILE(FILEA)
* Disconnect file
USE BUILTIN(DISCONNECT_FILE) WITH_ARGS(FILEA AS400SRV)
* Insert connect_file BIF here to connect file on the
* Other server, otherwise, it inserts to local DB
INSERT FIELDS(*ALL) TO_FILE(FILEA) VAL_ERROR(*NEXT)
* Insert disconnect_file BIF here to disconnect from Other server file
* Connect file - for the next record
USE BUILTIN(CONNECT_FILE) WITH_ARGS(FILEA AS400SRV)
ENDSELECT
RETURN
Reference Documents
LANSA for IBM i Guide Sections 5.4 What is Task Tracking
5.5 How to Invoke the Work With Tasks Facility
5.12 Exporting and Importing
Internal Database & System Utilities Sections 3.65 DC@F73 - TTS Export/Import File for External Systems
3.66 DC@F74 - TTS Object Register
3.67 DC@F75 - TTS Task Definition Log
3.68 DC@F76 - TTS Object Event Log
3.69 DC@F77 - TTS Export/Import Log for External Systems
21
Questions
22