Sage CRM Developers Course

1. Sage CRM Developers Course Coding the Web SelfService COM API (2)

2. Looking ahead to the classes • DP01: Introduction to the Development Partner Program • DP02: Entities and the Data Model (Part 1 of 2) • DP03: Entities and the Data Model (Part 2 of 2) • DP04: Implementing Screen Based Rules (Part 1 of 2) • DP05: Implementing Screen Based Rules (Part 2 of 2) • DP06: Screen and User Independent Business Rules • DP07: Workflow (Part 1 of 2) • DP08: Workflow (Part 2 of 2) • DP09: Using the API Objects in ASP Pages (Part 1 of 2) • DP10 : Using the API Objects in ASP Pages (Part 2 of 2) • DP11: Using the Component Manager • DP12: Programming for the Advanced Email Manager • DP13: Using the Web Services API • DP14: Using the Web Services API (Part 2 of 2) • DP15: Coding the Web Self Service COM API (Part 1 of 2) • DP16: Coding the Web Self Service COM API (Part 2 of 2) • DP17: Using the .NET API (Part 1 of 2) • DP18: Using the .NET API (Part 2 of 2)

3. Agenda • Using VisitorInfo • Building a Page • Role of Style Sheets • Building Hyperlinks • Client Side Coding • Search Select Advanced Limitations • Security

4. API Limitations • Previously discussed the lack of Session information. • Self Service doesn’t require a USER logon which is used in Application Extension ASP pages. • This places limits on what Blocks are available and changes the nature of other blocks.

5. COM Objects available in the Self Service API

6. COM Objects not available in Self Service API

7. General Observations • Build your own Blocks in meta data. (Don’t reuse existing blocks) You are in control You decide which fields are used No clashes with core system • Keep Screen and List Meta Data definitions simple You can add behavior later in code (see list hyperlink behavior) Avoid using Search Select Advanced Fields (see later example) • Keep HTML Pages simple Watch out for ‘normalisation’ behavior (see slide on Person screen) Avoid Compound Edit screens where you are editing several records at once (e.g. Company and Contact details)

8. VisitorInfo • CRM.VisitorInfo() • Property Syntax • CRM.VisitorInfo(ByVal FieldName As String) As String • The VisitorInfo property is addressable • CRM.VisitorInfo("visi_ipaddress") = Request.ServerVariables("REMOTE_ADDR"); • CRM.VisitorInfo("visi_middlename") = PersonRecord.pers_middlename; • Information is held in Visitor table

9. VisitorProfile table • If you write to a property that is unknown to the Visitor table it will get added to the VisitorProfile table • For example • CRM.VisitorInfo("TestProfile") = "Anything Goes"; • Response.Write(CRM.VisitorInfo("TestProfile"));

10. Processing Tricks for VisitorInfo • The CRM.VisitorInfo() is not a collection and is not enumerable but it is possible to access the Visitor table using CRM.FindRecord() method • For example • var myRecord = CRM.FindRecord("visitor","visi_personid="+intRecordId); • e = new Enumerator(myRecord); • Response.Write("<table class=content width='50%'>"); • while (e.item()) • { • if (CRM.VisitorInfo(e.item())) • { • Response.Write("<tr><td class='row1'>"+e.item()+"</td><td class='row2'>"+CRM.VisitorInfo(e.item())+"</td></tr>"); • } • e.moveNext(); • } • Response.Write("</table>");

11. Accessible Visitor Information • The Visitor and VisitorProfile tables are linked tables • The Administration List and Screens maybe changed. • Note: • To allow Reports and Groups to reference Self Service data appropriate views must first be created.

12. Building a Page • Basic List Page Code if (!CRM.Authenticated) { eWareLogin(); } else { var myBlock = CRM.GetBlock("SolutionList"); Response.Write(myBlock.Execute()); } • Pages Appearance Governed by General HTML Block definition Style Guide • Style Guide very important as Sage CRM blocks generate HTML tags which reference fixed style class names.

13. Style Sheets • Generated HTML • <SPAN ID=_Dataoppo_description class=VIEWBOX STYLE=WIDTH:"100px"> • Test • </SPAN> • </TD> • <input type=hidden name=_HIDDENoppo_description value="test"> • <TD VALIGN=TOP > • <SPAN ID=_Captoppo_source class=VIEWBOXCAPTION> • Source: • </SPAN> • <br> • <SPAN ID=_Dataoppo_source class=VIEWBOX STYLE=WIDTH:"100px">&nbsp;</SPAN> • </TD> • <input type=hidden name=_HIDDENoppo_source value="“ • <TD VALIGN=TOP > • <SPAN ID=_Captoppo_type class=VIEWBOXCAPTION> • Type:</SPAN> • <br> • <SPAN • Style Sheet • BODY{ • background: LightSteelBlue; • } • .EDIT{ • background:white ; • color:navy; • font-family: Tahoma,Arial; • font-size:13px; • } • .VIEWBOX{ • background:Skyblue ; • color:navy; • font-family: Tahoma,Arial; • font-size:13px; • } • .VIEWBOXCAPTION{ • color:NAVY; • font-weight:light; • }

14. List Block Properties • List Blocks • RowsPerScreen • Works very well in Self Service • In Core System user preferences to overrule this. var OppoListSSBlock = CRM.GetBlock("OppoListSS"); OppoListSSBlock.RowsPerScreen = 5; • Show Select as Gif • Assumes path to installed CRM

15. Building List Block Hyperlinks in Meta Data • In Meta Data definition of a List there is property • You should create links using Custom Jump.

16. Building List Block Hyperlinks in Code • Jumping to Core Entity Lead Opportunity Person Company Case • var persBlock = OppoBlock.GetGridCol("oppo_primarypersonid"); • with (persBlock ) • { • JumpEntity= "Person"; • } • This automatically adds the link to a file called persondetails.asp etc and prepares to pass the linking field in querystring (e.g. oppo_primarypersonid) • Jumping to Custom Location • var GridCol = OppoBlock.GetGridCol("oppo_description"); • with (GridCol) • { • JumpAction= 430; • CustomActionFile = "editoppo.asp"; • CustomIdField = "oppo_opportunityid"; • }

17. Client Side Coding • Screen Blocks provide you with • onChange • Custom Content • HTML generated by Blocks use the Span IDs • <SPAN ID=_Captoppo_description class=VIEWBOXCAPTION> • Description: • </SPAN> • <br> • <SPAN ID=_Dataoppo_description class=VIEWBOX STYLE=WIDTH:"100px"> • Test • </SPAN> • </TD> • N.B. Clientside CurrentUser Object is not available. • No user session!

18. Search Select Advanced • Search Select Advanced fields can not be rendered correctly as they make use of <iframes> with calls to the dll containing the session ID. • This means that fields must be • either constructed manually • Or Not displayed

19. Manual Construction of a Field • For example in a Self Service Person Screen the Meta Data may exclude the pers_companyid field as this is a Search Select Advanced. • A field can be added in to the ASP code. • By adding the field in the code we can force the EntryType to be other than Search Select Advanced and we can give it the field name in HTML that will cause its data to be submitted to the record correctly. • var pers_companyidBlock = CRM.GetBlock("entry"); • with(pers_companyidBlock) • { • EntryType = 10 • FieldName = "pers_companyid"; • Caption = CRM.GetTrans("colnames","pers_companyid"); • NewLine = true; • } • myBlock.AddBlock(pers_companyidBlock) • Assumptions • myBlock is the screen block (EntryGroup)

20. Required Field Control • The Self Service API does not inherit the Field Level security settings. This includes the mandatory setting for fields. This is because field level security uses Session Information. • Fields need to be made Mandatory in Meta Data screen definitions or in Code • var oppo_descriptionBlock = opportunitydetailboxBlock.GetEntry("oppo_description"); • oppo_descriptionBlock.Required = true;

21. Control of Mode • Check for Mode are possible in Entry and Edit Screens • if (CRM.Mode==View) • { • CRM.Mode = Edit; • }

22. Controlling Buttons • Default Button (Save/Change) controlled by • DisplayButton(Button_Default) = false; • Button Location controlled by Container/EntryGroup properties • ButtonLocation = Right; • ButtonAlignment = Top; • ButtonTitle property if (CRM.Mode==Edit) { myBlock.ButtonTitle = CRM.GetTrans("Button","save"); } else { myBlock.ButtonTitle = CRM.GetTrans("Button","edit"); }

23. Q&A

24. Looking ahead to the classes • DP01: Introduction to the Development Partner Program • DP02: Entities and the Data Model (Part 1 of 2) • DP03: Entities and the Data Model (Part 2 of 2) • DP04: Implementing Screen Based Rules (Part 1 of 2) • DP05: Implementing Screen Based Rules (Part 2 of 2) • DP06: Screen and User Independent Business Rules • DP07: Workflow (Part 1 of 2) • DP08: Workflow (Part 2 of 2) • DP09: Using the API Objects in ASP Pages (Part 1 of 2) • DP10 : Using the API Objects in ASP Pages (Part 2 of 2) • DP11: Using the Component Manager • DP12: Programming for the Advanced Email Manager • DP13: Using the Web Services API • DP14: Using the Web Services API (Part 2 of 2) • DP15: Coding the Web Self Service COM API (Part 1 of 2) • DP16: Coding the Web Self Service COM API (Part 2 of 2) • DP17: Using the .NET API (Part 1 of 2) • DP18: Using the .NET API (Part 2 of 2)