Miscellaneous JS API

Offline persistence of formula field calculations

Please see previous discussion about formula fields and stale data.

To persist formula fields from the Javascript API, you must call calculateSaveFormulas.

var request = { 
    "type"   : "calculateSaveFormulas",
    "object" : "Some_Custom_Object__c", // the object type
    "data"   : {
        // optional list of objectIds (must be of the same object type as specified.
        "objectIds"     : [ "a025000000iW9YuAAK", "a0250000005thYuAnp" ],
        // optional where clause (additional way to select specific objects)
        "whereClause"   : "Type = 'Bodega' OR Type = 'Supermarket'",
        // optional list of specific formula fields to calculate. If you don't pass this parameter, it will calculate and save all formulas.
        "formulaFields" : [ "Total_Price__c", "Some_Other_Formula_Field__c" ]
    }
};
bridge.sendRequest(request, function (responseData) { alert('Javascript got its calculateSaveFormulas response: ' + responseData); });

WARNING: this can be an incredibly expensive and slow operation if you do not specify any filter criteria. Therefore we recommend that you always include objectIds and/or whereClause parameters.

HTTP Callout API

The callout API is available for making HTTP(S) requests from the Pulsar platform and returning results to the HTML and javascript. Since custom HTML/javascript code is hosted as a local file within Pulsar, there can be issues using the normal XMLHttpRequest (XHR) or fetch methods to issue Cross-Origin requests to external services. This Pulsar API helps sidestep those problems.

var request = {
    type: 'callout',
    object: '',
    data: {
       resource: 'https://my.org.instance.salesforce.com/api/resources',
       options: {
           method: 'POST', // or GET, PUT, DELETE, etc...
           headers: { // header name-value pairs, as shown below
              Authorization: 'Bearer AABBEEAARREERRTTOOKKEENN....',
              Content-Type: 'application/json', // with Salesforce POST/PUT requests this will most often need to be 'application/json'
           },
           body: 'my post content body!', // this should ALWAYS be a string value- use JSON.stringify or similar to create JSON from javascript objects
       }
    }     
};
pulsarBridge.sendRequest(request, function (result) {
   if (result.type === 'calloutResponse') {
      var response = result.data;
      console.log('Response Status Code: '+response.status); // string
      console.log('Response Data:'+response.body); // string
      
   }
   else {
      console.log('failed: '+ result.data)
   }
});

Communicating with the Home App

Pulsar allows for the development of a Home App that runs in place of the usual native Pulsar application. Pulsar Field Service Lightning is an example of one such Home App. When developing custom documents, it may be useful to communicate with the Home App through the dispatchtohomeapp API.

Pulsar FSL Examples

// Go Home -- dismiss all open native Pulsar pages and documents and navigate FSL to the schedule screen and select today's date //
var goHomeRequest = {
  type: 'dispatchtohomeapp',
  object: '',
  data: {
    action: 'goHome',
    parameters: {},
  },
}

pulsarBridge.sendRequest(goHomeRequest, function (result) {
  if (result.type == 'dispatchtohomeappResponse') {
    // handle the success case //
    // the 'goHome' action tells Pulsar FSL to dismiss all native pages (possibly including the one sending this message)
    // and navigate to the Schedule page with today's date selected. 
    console.log('PulsarFSL navigated to the Home Screen');
  } else {
    // This may happen if the format of your data block in the request is unhandled or malformed. //
    console.log('PulsarFSL failed to handle goHome action: ', result.data);
  }   
});

// View Object - the 'view' action allows for direct navigation to objects in the FSL context. It is important to note that many SObject types 
// are not handled by FSL and may result in undesired behavior. Valid parameters for the object field are 'ServiceAppointment', 'WorkOrder',
// and 'WorkOrderLineItem'. 
var viewRequest = {
  type: 'dispatchtohomeapp',
  object: '',
  data: {
    action: 'view',
    parameters: {
      object: 'WorkOrder',
      Id: 'aValidWorkOrderId',      
    },
  },
};

pulsarBridge.sendRequest(viewRequest, function (result) {
if (result.type == 'dispatchtohomeappResponse') {
    // handle the success case //
    // the 'view' action tells Pulsar FSL to navigate to the provided object's overview page within FSL.
    console.log('PulsarFSL attempted to navigate to the page.');
  } else {
    // This may happen if the format of your data block in the request is unhandled or malformed. //
    console.log('PulsarFSL failed to handle view action: ', result.data);
  } 
});

Custom Home App Examples

When interacting with your own custom home app, you are responsible for handling all dispatchtohomeapp interaction. This is achieved through a registration API call: registerdispatchtohomeapp. The following example comes from our own Pulsar FSL application. After we have access to the Pulsar bridge object we perform some custom setup to handle messaging from other documents and our own internal messaging.

The two actions we demonstrate here are actions that are triggered through common events in the native Pulsar UI. Your custom home app may want to respond to these as well. If your custom home app has registered for dispatchtohomeapp, any tap on a native Pulsar Home Button will fire the ‘goHome’ action. Similarly, when a deep link is opened in Pulsar, the “view” action will be fired with the object type and Id in the parameters of that call. Your custom home app may wish to respect any of these actions.