1
0
-1

Hi,


In a Salesforce to Jira on premise connection, we must prevent the synchronisation because the Salesforce Case lacks some fields we need before creating a Jira issue.


Our core need is to have the "Connect" button only on Salesforce.

It comes via the Exalate component, with the "Exalate" button.

So we want to behave safely if anyone press this "Exalate" button, that means raise a warning and do nothing.


On Salesforce, the Exalate component is displayed, showing the "Exalate" and "Connect" buttons. This component is here only for the "Connect" button but, unless we can get rid of the "Exalate" button, we have to set some safety rules. If a user press the "Exalate" button, that starts a synchronisation that never complete because on Jira side the issue creation is failing, because of missing/null values.


We don't want to create new Issue with default values, they must come from Salesforce side.

We want to halt the synchronisation as early as possible.

We are thinking of some check in the outgoing script on Salesforce side, that detect the empty field and give up the synchronisation (that would otherwise be an error on Jira side).


In the Salesforce outgoing script, we tried things like:

if (entity.JiraProject__c?.value == null) {
  throw new Exception("No Jira Project selected, aborting.")
}

or

if (entity.JiraProject__c?.value == null) {
  return
}

The first one leaves a blocking error on the connection. The second generates no outcome but the status on the case is "WAITING_FOR_REMOTE". In both cases pressing the "Exalate" button result in a green Toaster message.


What could be the solution?


Regards,

Stéphane

  1. Stéphane Thillay

    Here is the steps that drove us to our current question.

    1. we have a trigger that start synchronisation (SF Case to new Jira Issue) when specific Case fields are populated (those used to fulfil the new Jira Issue)
    2. Users ask to connect SF Case to existing Jira Issue
    3. We add the Exalate component on Case page to get the "Connect" button
    4. We can't get rid of the "Exalate" button from the same component
    5. We look for a way to make the "Exalate" button without effect, in case a user clicks it by mistake
    6. We tried to throw an exception, a bare return and now an assert. Nothing fits.
CommentAdd your comment...

1 answer

  1.  
    3
    2
    1

    Whenever the replica object is unmodified (in the outgoing sync script), there will be no sync transaction created.


    The advice is to assert at the beginning of the outgoing scripts all the conditions.  Whenever these are not met, return without changing the replica.


    1. Stéphane Thillay

      Adding an assert in the outgoing script stops processing when condition isn't matched.

      In the outgoing script:

          assert entity.JiraProject__c?.value != null


      Either the syntax is wrong (I want to stop in case the JiraProject field is empty), or the assert is a bit rude. The result of pressing the "Exalate" button on a Case give an error on the connection:


      com.exalate.api.exception.bug.BugException ... Caused by: Assertion failed: assert entity.JiraProject__c?.value != null 


      It looks the assert is like the exception we tried: it generates an error that block the connection.


      We want the "Exalate" button to be ineffective and harmless. We have our custom process that needs the user to populate few field on the Case, then an exalate trigger will start the synchronisation (and create a Jira issue).



    2. Stéphane Thillay

      The key is:

      "Whenever the replica object is unmodified (in the outgoing sync script), there will be no sync transaction created."


      By putting as early as possible a test on the mandatory fields and a return if they are empty, nothing happens. No error on the connection, 


    3. Francis Martens (Exalate)

      Stéphane Thillay 

      When I was stating 'assert', I didn't mean the assert operation, but the fact to check the conditions.

      You can easily try it out with


      if (entity.summary == "ignore") {
         return
      }


      This will not generate an error, but ignore any updates done on an entity where the summary is 'ignore'


    CommentAdd your comment...