Encompass SDK Learning Guide
Ellie Mae is rolling out Encompass SDK Training classes. Contact your account rep to check.
Want to kick-start your development from zero to hero? Let us know, we can provide many reusable components and source code.
This guide should be useful to someone familiar with Visual Studio, Object Browser, and reasonable development and debugging techniques from prior C# or VB.NET projects. It's supposed to be used together with the Encompass 360 SDK Programmer's Guide SDKProgrammersGuide.pdf and Encompass Object Help file EncompassObjects.chm found in C:\Program Files (x86)\Encompass\Sdk\Docs.
I would highly recommend to read or selectively read/scan the SDK Guide before you start doing any projects. I would also recommend to re-read it again after the first ~ 5 projects, as it may bring attention to more details that are easy to miss when you are not familiar with Encompass objects, functions or functionality. Generally, Object Browser is the easiest to use to see what the objects and functions are, while Encompass Objects Help file can be checked to see if there are usage pointers or code examples for specific functions such as, for example, GetFixedRole(), BorrowerPair.Borrower, ...
There are 3 main types of projects that can be done with Encompass SDK.
1. Form CodeBase DLLs. These DLLs are specific to one or more forms. Generally they enhance functionality of the form via more complex event handling or control manipulation than Form Builder can allow. They can also add Windows UI dialogs to the form. Usually, Encompass loads these DLLs when forms attached to these DLLs are loaded.
2. Global Plugin DLLs. These DLLs are loaded when Encompass starts. They can be used to hook into events such as Loan Opening, Field changes, Document changes, ... and act on such changes when the user is in any form or tool inside Encompass.
3. Separate EXEs or services. Generally, these would be projects doing reporting, loan creation, loan updates, user management, ... They can be executables, with or without UI, WinForms, WPF, web services or windows services. These types of projects will require Encompass SDK installed and registered with the SDK key on the computer where they execute. First two project types - CodeBase DLLs and Plugin DLLs run inside Encompass and do not need Encompass SDK to be installed for execution.
The best way to learn functionality of the SDK, as well as to demonstrate how it is useful for business, is by doing several sample projects. I would recommend the following path and set of projects:
Projects For Self-Learning
1. Form CodeBase DLL that shows some Windows UI from a button on a custom Encompass form is the best starting point. Ideally, this should be a Windows UI that lists something difficult to do in Encompass Forms or via Form Builder code. This would be a good first demo of what SDK can do.
For example, make a custom form with a button which shows 2 lists of documents: 1) documents without attachment and 2) documents with small attachments (i.e. potentially fake files).
As another example, make a project which lists all conditions that do not have documents attached to them, call it "Conditions Without Docs", and another list of conditions which are not Cleared or Waived and call it "Pending Conditions".
"SampleInputScreen" sample is a good starting point for this project. Loan.Log object is a good starting point where to look for documents and conditions.
Important knowledge to take from the sample is:
1) [Plugin] is the magic attribute that makes your class loaded by Encompass.
2) You derive from EllieMae.Encompass.Forms.Form so that CreateControls() / OnLoad() and OnUnload() works.
3) You have access to Loan object.
4) You have access to all controls on the form via FindControl() function.
5) You can handle same events on each control that Form Builder shows.
6) In fact, Form Builder builds it's own code and events the same way!
- see this screenshot with actual Form Builder code
shown by Loan Debugger Tool from an intentional crash.
Both of these projects should immediately show 2 values to a good Business Analyst / Project Manager. Value #1 – Forms are no longer limited to a small set of controls from Form Builder. Standard Windows dialogs and their UI controls can be utilized if needed for more complex UI/UX. Value #2 – you can access documents & conditions and potentially make better tools or reports for Loan Processors and Underwriters.
2. Global Plugin is the best next step. The best demo and learning would be accomplished by a plugin that handles form changes, field changes, document changes or milestone changes.
Form Changes - make a plugin that simply has a list of "important fields". Then every time form changes, highlight all controls with such important fields in reddish color if they are blank. Form Builder would allow you to do this on custom forms. Yet a global plugin would allow you to do it across most of the standard forms as well. The reason why I say most - some forms do not trigger Form Load events. If you use our Loan Monitor Tool you will see those named as "Tab Forms" or "Tool Forms" as opposed to just "Forms".
Field Changes - make a plugin that reacts to [CX.ADDDOC] field and adds a document with name from [CX.ADDDOC].
Document Changes - If document is marked ReadyToShip, but it does not have attachments - revert it back to not Ready.
Milestone Changes - block Submission or Processing milestone if Signed 1003 doc is missing or if it is smaller than 1Mb. It's easy to block when document is missing with just milestone completion rules. However, it's not possible to use such rules to block based on document sizes. Likely a scanned or faxed signed 1003 will be > 1Mb.
Any of these demos should again show HUGE VALUE of the SDK to a good Project Manager or Business Analyst. They basically demonstrate that workflow and internal Encompass processes can be augmented beyond standard business rules.
"LoanMonitor" sample is a good starting point for such global plugins. Our Loan Monitor Tool is also very useful for working on projects like these, since it shows all Encompass events which you can use in your plugins. It can also safely be placed on your production server to allow you debug issues without affecting anyone else.
Important knowledge to take from the sample is:
1) [Plugin] is the magic attribute that makes your class loaded by Encompass.
2) Application object has events for Opening/Closing loan.
3) CurrentLoan object has the loan after it's opened.
4) CurrentLoan object has events you can hook into.
The best architecture for global plugins that I found is not how the sample is written though. What I normally do is create a separate class for each "hook" and name it specifically. I.e. FieldMonitor_BlockMilestones or DocMonitor_RejectConditions, ... Each has Start/Stop functions and allows to jump to important code in each project very quickly if debugging/tracing is needed.
3. Stand Alone Projects. The best example for any company that started using Encompass before 2013 would be a project that enumerates all loans, opens them one by one, then enumerates all document names and created a "hash" of how many times each document name is present in all loans. The reason for 2013 cutoff date is that Encompass 9.0, released in 2013, added a feature of locking down document names, which potentially allowed to fix the issue.
This project would kill 2 birds with one stone.
First, it would show that you can theoretically "report" on what's not normally reportable. Even though it takes a while (likely whole night since it takes 2-5 seconds to open a loan), it's still a report that can be executed with SDK and not with any other options.
Second, it may show to the company that you can identify all the potential typos/inconsistencies, and potentially improve this. Likely on a system with ~ 200 document names, you should find at least 200 other typos, misspellings and extra spaces.
Another likely good project would be a web service that creates a loan and returns GUID. This web service can take basic parameters like borrower name, address and loan amount. Together with a simple web page that takes such information, you can demonstrate that a custom hook into CRM, lead source, or phone system can be developed.
Generally, such projects start with establishing connection to Encompass Server by using EllieMae.Encompass.Client.Session object. First you call Start() function with server URL and user credentials, then you use that Session object to either access Loans, Users, Reports or to query loans using Loan or Pipeline queries as described in the SDK Guide.
Enjoy!