10 November 2014

Event Log File Field Lexicon

Event Log Files, new in the Winter '15 release, enables adoption, troubleshooting, and auditing use cases using an easy to download, file based API to extract Salesforce app log data.

It's an extremely rich data source, originally created by Salesforce developers to better understand the operational health of the overall service and better support our customers.

Extending access to these log files provides our customers the ability to support themselves using some of the same tools we've used to support them.

Most fields in the log files are self-describing like CLIENT_IP or TIMESTAMP. However, some of the log file fields can be difficult to understand without a lexicon.

There are a couple of reasons for this. One reason is because some fields are derived where data is encoded in an enumerated value or with an acronym which is defined in a separate place in the code.

A lot of time, this is done because less characters or numeric codes take up less total storage space which is important when you're storing terabytes of log files every day.

But this leaves us with a problem, what in the world does the data actually mean?

For instance, rather than store 'Partner' for the API_TYPE in the API log file, we store a simple code of 'P'.

Another example is when the code is spelled out and still needs interpretation. For instance, VersionRenditionDownload for the TRANSACTION_TYPE in the ContentTransfer log file simply means someone previewed a file in the app instead of downloading it (which is actually VersionDownloadAction or VersionDownloadApi).


All of this means we need a lexicon to map codes to possible values or examples so that we understand the data we're downloading.

Below are some example fields to help make sense of the data from Event Log Files.

Common Log File Fields
These are log fields you'll see across many different log files and typically address who, what, when, where, and how.

Field NameDescriptionPossible Values or Examples (e.g.)
CLIENT_IPThe IP address of the client using Salesforce services.e.g. 192.168.0.1
EVENT_TYPEThe type of event, such as content sharing.e.g. URI
ORGANIZATION_IDThe 15-character ID of the organization.e.g. 00DB00000000mZw
REQUEST_IDThe unique ID of a single transaction.e.g. 3nWgxWbDKWWDIk0FKfF5DV
REQUEST_STATUSThe status of the request for a page view or user interface action.Possible values include:
• S: Success
• F: Failure
• U: Uninitialized
TIMESTAMPThe access time of Salesforce services, in UTC time.e.g. 20130715233322.670,
which equals 2013-07-15T23:33:22.670+0000.
URIThe URI of the page receiving the request.e.g. /home/home.jsp
USER_IDThe 15-character ID of the user using Salesforce services, whether through the UI or the API.e.g. 005B00000018C2g

Log File Specific Fields
These are log fields that are typically unique to one or two log files and typically represent a type, operation, or other enumerated value.

EventType (File Type)Field NameDescriptionPossible Values or Examples (e.g.)
APEX_CALLOUT_EVENTMETHODThe HTTP method of the callout.e.g. GET, POST, PUT, DELETE
APEX_CALLOUT_EVENTTYPEThe type of calloute.g. REST, AJAX
APEX_TRIGGER_EVENTTRIGGER_TYPEThe type of this trigger.The types of triggers are:
• AfterInsert
• AfterUpdate
• BeforeInsert
• BeforeUpdate
API_EVENTMETHOD_NAMEThe API method that is invoked.e.g. query(), insert(), upsert(), delete()
API_EVENTAPI_TYPEThe type of API invoked.values include:
• X: XmlRPC
• O: Old SOAP
• E: SOAP Enterprise
• P: SOAP Partner
• M: SOAP Metadata
• I: SOAP Cross Instance
• S: SOAP Apex
• D: Apex Class
• R: REST API
• T: SOAP Tooling
ASYNC_REPORT_EVENTDISPLAY_TYPEThe report display type, indicating the run mode of the report.Possible values include:
• D: Dashboard
• S: Show Details
• H: Hide Details
ASYNC_REPORT_EVENTRENDERING_TYPEThe report rendering type, describing the format of the report output.Possible values include:
• W: Web (HTML)
• E: Email
• P: Printable
• X: Excel
• C: CSV (comma-separated values)
• J: JSON (JavaScript object notation)
CONTENT_DOCUMENT_LINK_EVENTSHARING_OPERATIONThe type of sharing operation on the document.e.g. INSERT, UPDATE, or DELETE.
CONTENT_DOCUMENT_LINK_EVENTSHARING_PERMISSIONWhat permissions the document was shared with.The possible values include:
• V: Viewer
• C: Collaborator
• I: Inferred—that is, the sharing permissions were inferred from a relationship between the viewer and document. For example, a document’s owner has a sharing permission to the document itself. Or, a document can be a part of a content collection, and the viewer has sharing permissions to the collection, rather than explicit permissions to the document directly.
CONTENT_TRANSFER_EVENTTRANSACTION_TYPEThe operation performed.The possible operations include:
• VersionDownloadAction and
VersionDownloadApi represent downloads via the user interface and API respectively.
• VersionRenditionDownload represents a file preview action.
• saveVersion represents a file being uploaded.
DASHBOARD_EVENTDASHBOARD_TYPEThe type of dashboard.Valid types include:
• R: Run as Running User
• C: Run as Context User
• S: Run as Specific User
LOGOUT_EVENTUSER_INITIATED_LOGOUTThe user type used when logging out.The value is 1 if the user intentionally logged out by
clicking the Logout link, and 0 if they were logged out by a timeout or other implicit logout action.
MDAPI_OPERATION_EVENTOPERATIONThe operation being performede.g. DEPLOY, RETRIEVE, LIST,
DESCRIBE
PACKAGE_INSTALL_EVENTOPERATION_TYPEThe type of package operation.Possible values include:
• INSTALL
• UPGRADE
• EXPORT
• UNINSTALL
• VALIDATE_PACKAGE
•INIT_EXPORT_PKG_CONTROLLER
REPORT_EVENTDISPLAY_TYPEThe report display type, indicating the run mode of the report.Possible values include:
• D: Dashboard
• S: Show Details
• H: Hide Details
REPORT_EVENTRENDERING_TYPEThe report rendering type, describing the format of the report output.Possible values include:
• W: Web (HTML)
• E: Email
• P: Printable
• X: Excel
• C: CSV (comma-separated values)
• J: JSON (JavaScript object notation)
REST_API_EVENTMETHODThe HTTP method of the requeste.g. GET, POST, PUT, DELETE
SITES_EVENTHTTP_METHODThe HTTP method of the requestGET, POST, PUT, DELETE
SITES_EVENTREQUEST_TYPEThe request type.Possible values include:
• page: a normal request for a page
• content_UI: a content request for a page
originated in the user interface
• content_apex: a content request initiated
by an Apex call
• PDF_UI: a request for a page in PDF format
through the user interface
• PDF_apex: a request for PDF format by an
Apex call (usually a Web Service call)
UI_TRACKING_EVENTCONNECTION_TYPEMethod used by the mobile device to connect to the web.Values can include:
• CDMA1x
• CDMA
• EDGE
• EVDO0
• EVDOA
• EVDOB
• GPRS
• HSDPA
• HSUPA
• HRPD
• LTE
• OFFLINE
• WIFI
VISUALFORCE_EVENTREQUEST_TYPEThe request type.Possible values include:
• page: a normal request for a page
• content_UI: a content request for a page
originated in the user interface
• content_apex: a content request initiated
by an Apex call
• PDF_UI: a request for a page in PDF format
through the user interface
• PDF_apex: a request for PDF format by an
Apex call (usually a Web Service call)

03 November 2014

Hadoop and Pig come to the Salesforce Platform with Data Pipelines


Event Log Files is big - really, really big. This isn't your everyday CRM data where you may have hundreds of thousands of records or even a few million here and there. One organization I work with does approximately twenty million rows of event data per day using Event Log Files. That's approximately 600 million rows per month or 3.6 billion every half year.

Because the size of the data does matter, we need tools that can orchestrate and process this data for a variety of use cases. For instance, one best practice when working with Event Log Files is to de-normalize Ids into Name fields. Rather than reporting on the most adopted reports by Id, it's better to show the most adopted reports by Name.

There are many ways to handle this operation outside of the platform. However, on the platform there's really only been one way to handle this in the past with Batch Apex.

In pilot with the Winter '15 release (page 198 of the release notes), data pipelines provides a way for users to upload data into Hadoop and run Pig scripts against it. The advantage is that it handles many different data sources including sobjects, chatter files, and external objects at scale.

I worked with Prashant Kommireddi on the following scripts which help me understand which reports users are viewing:

1. Export user Ids and Names using SOQL into userMap.csv (Id,Name) which I upload to chatter files
-- 069B0000000NBbN = userMap file stored in chatter
user = LOAD 'force://chatter/069B0000000NBbN' using gridforce.hadoop.pig.loadstore.func.ForceStorage() as (Id, Name);
-- loop through user map to reduce Id from 18 to 15 characters to match the log lines
subUser = foreach user generate SUBSTRING(Id, 0, 15) as Id, Name;
-- storing into FFX to retrieve in next step
STORE subUser INTO 'ffx://userMap15.csv' using gridforce.hadoop.pig.loadstore.func.ForceStorage();

2. Export report Ids and Names using SOQL into reportMap.csv (Id,Name) which I upload to chatter files
-- 069B0000000NBbD = reportMap file stored in chatter
report = LOAD 'force://chatter/069B0000000NBbD' using gridforce.hadoop.pig.loadstore.func.ForceStorage() as (Id, Name);
-- loop through user map to reduce Id from 18 to 15 characters to match the log lines
subReport = foreach report generate SUBSTRING(Id, 0, 15) as Id, Name;
-- storing into FFX to retrieve in next step
STORE subReport INTO 'ffx://reportMap15.csv' using gridforce.hadoop.pig.loadstore.func.ForceStorage();

3. createReportExport - Upload ReportExport.csv to chatter files and run script to combine all three
-- Step 1: load users and store 15 char id
userMap = LOAD 'ffx://userMap15.csv' using gridforce.hadoop.pig.loadstore.func.ForceStorage() as (Id, Name);
-- Step 2: load reports and store 15 char id
reportMap = LOAD 'ffx://reportMap15.csv' using gridforce.hadoop.pig.loadstore.func.ForceStorage() as (Id, Name);
-- Step 3: load full schema from report export elf csv file
elf = LOAD 'force://chatter/069B0000000NB1r' using gridforce.hadoop.pig.loadstore.func.ForceStorage() as (EVENT_TYPE, TIMESTAMP, REQUEST_ID, ORGANIZATION_ID, USER_ID, RUN_TIME, CLIENT_IP, URI, CLIENT_INFO, REPORT_DESCRIPTION);
-- Step 4: remove '/' from URI field to create an Id map
cELF = foreach elf generate EVENT_TYPE, TIMESTAMP, REQUEST_ID, ORGANIZATION_ID, USER_ID, RUN_TIME, CLIENT_IP, SUBSTRING(URI, 1, 16) as URI, CLIENT_INFO, REPORT_DESCRIPTION;
-- Step 5: join all three files by the common user Id field
joinUserCELF = join userMap by Id, cELF by USER_ID;
joinReportMapELF = join reportMap by Id, cELF by URI;
finalJoin = join joinUserCELF by cELF::USER_ID, joinReportMapELF by cELF::USER_ID;
-- Step 6: generate output based on the expected column positions
elfPrunedOutput = foreach finalJoin generate $0, $1, $2, $3, $4, $5, $7, $8, $10, $11, $12, $13;
-- Step 7: store output in CSV
STORE elfPrunedOutput INTO 'force://chatter/reportExportMaster.csv' using gridforce.hadoop.pig.loadstore.func.ForceStorage();

By combining the power of data pipelines, I can transform the following Wave platform report from:

To:


To learn more about data pipelines and using Hadoop at Salesforce, download the Data Pipelines Implementation Guide (Pilot) and talk with your account executive about getting into the pilot.

27 October 2014

Tracking User Activity Across Browsers and Mobile Devices

I'm often asked whether we can track user activity at a more granular level than what's currently provided with Login History, Setup Audit Trail, and other existing monitoring features in Salesforce.

When I tell them yes, people's imaginations immediate kick into over-drive. Without understanding what is possible, people begin to imagine every possible way data can be accessed whether through a button click, running a report, viewing a list view, hovering over a related list, or looking at search results.

There are many ways users may interact with data in Salesforce. This blog post is designed to separate out fact from fiction when understanding how granular we can track user activity while working with the new Event Log Files functionality.

Event Log Files provides self-service access for customers to server generated log records. This means that a server interaction had to happen in order to record the event. The most typical server interaction is the change in a URI (uniform resource identifier, analogous to the URL you see in your address bar).


For example, when I clicked on the Marc Benioff contact record from the Home tab, the URL in the address bar changed by adding the contact id. As a result, the entry in the log file shows a Referrer URI of /home/home.jsp and a URI of /0033000000Vt4Od.

This URI interaction unto itself is powerful considering salesforce grew up as a native web application. Most things that we click ultimately change the URI. The easiest way to test this is to click something in the application and see if the address bar changes.

De-coding the URIs isn't difficult, it just takes a lexicon:
Standard object based pages:

/d: Detail- Detailing a single record and with its associated records
/m: Hover- HoverDetail page that uses a mini layout and no header/footer
/e: editPage Allowing the editing of a single record
/p: printableView- In a relatively unadorned format, detailing a single record and all of its associated records.
/o: Overview of a single entity.
/l: list- A filtered list of a single entity
/x: Printable list: A filtered list of a single entity. Does not have a help link, since you can't click links on paper.
/r: Refresh list: A stripped down version of a list filtered by ids
/s: special: Special is used for "other" pages where you want to reuse parts of the edit/detail page
/h: history: Show the history (used only in forecasting)
/a: Assign: Entity Owner Change page
/c: calendar: Time-based (Calendar) view of list data
/n: mini edit: Mini layout edit page

Custom Objects based Pages

/d: Detail
/m: Hover
/e: Edit
/p: Printable View
/o: Overview
/l: List
/x: Printable List
/a: Assign
/r: Refresh List

We can now track when someone prints a page or list view, edits a record or creates one, changes ownership, or even refreshes a list.

URI events mainly track what happens in the browser. In order to track similar interactions on a mobile device using a Salesforce 1 application, we have a separate UI Tracking log event.

At Dreamforce 2014's True to the Core session Mark Bruso asked me about this distinction and what we actually track.

Most of the time, when people ask about Salesforce 1 mobile, it's to validate the effectiveness of a BYOD (Bring Your Own Device) mobile strategy with a focus on the type of device, network used, and operating system of choice. The goal is typically to rationalize an investment in mobile in addition to understanding what their users are doing when they are in a Salesforce 1 application.


However, we also track a couple key attributes in the UI Tracking log file including Referrer and Action. This are analogous to the URI and Referrer URI attributes in the URI log file.

When you combine these two data sets, the big picture emerges across these different platforms. Now we can track what's happening with a user regardless of whether they use a browser or a mobile phone.


This is powerful for answering questions like:
  1. What % of my users are in the browser versus on the phone?
  2. Where are users using their mobile devices since they may be on the road?
  3. Where are my users spending their time and on what records?
  4. How frequently are they logging in and what hours of the day?
  5. Who clicked on what, when, where, and how?
Tracking user activity in salesforce isn't rocket surgery. We can't track everything a client side script might, but we can track a lot. And what we track enables us to re-create what a user did and paint a picture that helps address a variety of adoption, troubleshooting, and audit use cases.