CRM/SFA Developers Overview

This is a technical document gives a technical overview of the opentaps CRM/SFA module. It is
intended for experienced F!I" developers who would li#e to understand the structure of the
opentaps CRM/SFA application and how it differs from the other F!I" applications.
Change Log
July 26, 2006 General UI philosophy
July 11, 2006 Initial version
2006 Open Source Strategies, Inc. All ights eserve!.
"age 1 o# 3
CRM/SFA Developers Overview
The Architecture
$he %&'S(A application !i##ers #ro) other O(*i+ applications in a very #un!a)ental ,ay. -hile
the O(*i+ applications are !esigne! to .e a set o# generic applications .uilt ,hich coul! .e
t,ea/e! or custo)i+e! to #it al)ost any type o# .usiness process, the %&'S(A application is
!esigne! speci#ically to support the roles an! tas/s co))only per#or)e! in a %& application.
As such, this has le! to so)e i)portant !i##erences .et,een %&'S(A an! other O(*i+
applications0
1. $he .usiness logic o# the %&'S(A application is less granular than that o# O(*i+ an!
typically aggregates several actions ,hich are o#ten per#or)e! separately in O(*i+. (or
e1a)ple, ,hen an account is create!, the %&'S(A application ,ill call !i##erent O(*i+
services to create "arty, "artyGroup, "artyole, "artyelationship, an! several
%ontact&ech, "ostalA!!ress, $eleco)2u).er entities an! associate the) ,ith the
account party.
2. 3ighly generic !ata )o!el concepts #ro) O(*i+ are presente! to users in )ore
tra!itional concepts. (or e1a)ple, 4"arty5 is presente! to the user as account, lea!,
contact, tea), or tea) )e).er, each ,ith !i##erent user inter#ace an! .usiness logic.
6. $he O(*i+ concept o# 4-or/7##ort5 is presente! to the user as 4Activity5, an! only 7vents
an! $as/s are availa.le as activities. Other types o# -or/7##ort, such as )anu#acturing
pro!uction run process, are not sho,n in the %&'S(A application.
8. $here is a !i##erent security )o!el centere! aroun! "artyelationship.securityGroupI! to
!e#ine the security per)issions .et,een t,o parties 9ie, !oes tea) )e).er A have
per)ission to !o this #or account *:; $his uses a !i##erent security )etho! 9see 4Security
<ocu)entation5 #or !etails.;
User Interace !hilosoph"
$he %&'S(A application has a user inter#ace philosophy ,hich is !i##erent than that o# the other
O(*i+ applications. *rie#ly state!, this philosophy is to create an interace or what the user
un#erstan#s an# wants to #o$ rather than %a&e the user thin& li&e "our application'
(or e1a)ple, 4,or/ e##ort5 is an O(*i+ concept o# a tas/, a pro=ect, an event, or a )anu#acturing
pro!uction step, an! the O(*i+ -or/7##ort application allo,s the user to )anipulate ,or/ e##ort
.y creating ,or/ e##orts, up!ating its #iel!s, associating parties, co))unication events, etc. etc.
,ith ,or/ e##orts. $hese screens are on separate ta.s o# the -or/7##ort application, ,ith each
ta. sho,ing a !i##erent #acet o# the application.
&ost users, ho,ever, !o not thin/ o# 4I ,ant to create a ,or/ e##ort an! then assign "arty > an!
"arty ? to it.5 $hey thin/ 4I have an appoint)ent ,ith "arty > an! "arty ? at noon to)orro,.5
$hus, the %&'S(A application gives the user screens to create an appoint)ent an! then a!!
parties > an! ? to it, start the appoint)ent, an! then co)plete it.
$his, o# course, )eans that so)e operations ,hich are possi.le in O(*i+ ,oul! not .e supporte!
.y the user inter#ace o# the %&'S(A application. (or e1a)ple, it is possi.le in O(*i+ to create a
,or/ e##ort o# the type 47vent5 an! then associate ,ith a ship)ent or )anu#acturing pro!uction
run. $hose #iel!s are visi.le on the ,or/ e##ort screens in O(*i+, even i# the ,or/ e##ort in
@uestion is an 4event5 ,hich usually !oes not have those #iel!s associate! ,ith it. In contrast, in
the %&'S(A application ,e !o not )a/e those #iel!s availa.le to the user. I# at a later !ate ,e
nee! to support activities ,hich are relate! to ship)ents or )anu#acturing, ,e ,ill )ost li/ely
create a !i##erent screen or other,ise )a/e the #iel!s appear only in the appropriate conte1t.
$his loss o# #unctionality is accepta.le .ecause it )a/es the )ost co))only per#or)e!
operations easier to un!erstan!, an! .ecause the O(*i+ applications coul! .e use! to support
these less co))on operations ,hen they are necessary.
2006 Open Source Strategies, Inc. All ights eserve!.
"age 2 o# 3
CRM/SFA Developers Overview
Another part o# the UI philosophy is to consoli!ate several operational steps into one userAvisi.le
step. $he .est e1a)ple o# this is ,hen you create a contact, you can enter all o# the userBs
contact in#or)ation on one screen, an! the syste) ta/es care o# the un!erlying !etails #or
creating the party, contact in#or)ation, an! associating the), essentially ,rapping a ,hole .unch
o# O(*i+ calls into one.
(inally, ,e ,ant to avoi! )a/ing the user to clic/ .ac/ an! #orth to loo/ #or in#or)ation, so )ost
screens are presente! ,ith all the in#or)ation on one screen, rather than several ta.s ,hich
sho, each part o# the in#or)ation.
Co#ing Conventions
In a!!ition, to .uil! the %&'S(A application, ,e have !evelope! a set o# co!ing conventions
,hich are so)e,hat !i##erent as ,ell0
1. $o en#orce a stronger separation .et,een vie, an! !ata preparation, ,e restrict the vie,
layer arti#acts such as #ree)ar/er pages an! #or) >&C !e#initions to present !ata only.
$his )eans no use o# 4actions5 tag insi!e o# #or) ,i!gets, #or e1a)ple.
2. In the screen ,i!get !e#initions, use .eanshell scripts rather than the DentityAoneE >&C
actions #or !ata preparation.
6. 2o )inilang co!e longer than 10 lines in a )etho!. Use Java #or )ore co)ple1 services
an! .usiness logic. <o not !o co)parisons ,ith neste! DorE Dan!E or calculations in
)inilang.
8. Feep co!e .loc/s s)all. Generally, i# you have )etho!s over 200 lines long, thin/ har!
a.out ho, to reA#actor the).
G. %o))ent your co!e. <escri.e ,hy you are !oing ,hat you are !oing in the co!e, not
=ust ,hat you are !oing. (or e1a)ple, i# you have co!e li/e this
invoiceI! H nullI
<onBt ,rite co))ent
'' Set invoiceI! to null
Instea! ,rite
'' InvoiceI! )ust .e null or the service ,ill not create a ne, invoice
6. Use long varia.le an! )etho! na)es, li/e co)pute(orecast"arent"erio!, instea! o#
shorter ones.
7. Use varia.le na)es ,hich )irror the entities they re#er to, an! #o not a((reviate such
varia(le na%es. (or e1a)ple, i# you get a list o# or!erIte)s, !o not =ust call the)
4ite)s5Jcall the) 4or!erIte)s5 an! 4ne1tOr!erIte)5, etc. I# you get a list o#
Or!er"ay)ent"re#erence entities, !o not call the) 4pay)ents,5 .ecause there is a
"ay)ent entity ,hich !oes so)ething very !i##erent.
K. Use Java 3elper )etho!s in a separate class to support co)ple1 #unctions in ($C, #or)
,i!gets, .eanshell, an! Java services.
L. (ollo, a !ivision o# co!e to )irror the !ivision o# sections o# the application. $here are
separate #or) an! screen ,i!get >&C !ocu)ents in the ,i!gets' !irectory, separate Java
pac/ages in src', separate ($C in ,e.app'cr)s#a', an! separate *S3 scripts in
,e.app'cr)s#a'-7*AI2('actions' #or accounts, contacts, lea!s, etc.
10. %o))ent ,hat services !o in the services >&C !escription section an! point out
anything special or une1pecte! a.out the service.
2006 Open Source Strategies, Inc. All ights eserve!.
"age 3 o# 3