LDAP Integration: Performing a User search in Group

If you are synchronising users from one system to LDAP, you can check if the User is a member of a Group before adding the User into the Group. This can be achieved by using the LDAP connector. You can do this by providing the User CN and Group DistinguishedName into the filters.
For example, we can put the following details into the filters of connector to perform the search:

 User CN: 112233
Group DistinguishedName: CN=My_Group,OU=User_Groups,DC=test,DC=wdci,DC=com,DC=au
This is the result we will get if the user is found in the group:

 <result>
<status>Found</status>
<message>User 112233 found in group CN=My_Group,OU=Students,OU=User_Groups,DC=test,DC=wdci,DC=com,DC=au</message>
</result>

Understanding Salesforce Object Relationships

There are many skill variations when it comes to Salesforce system implementation and Salesforce integration. One of it requires an understanding on the object relationship within the application. It is not hard to comprehend the relationship once you can identify the data model that you are about to build. The following are some of the common object relationships that are used to define the data model:

1. One to One
2. One to Many/Many to One
3. Many to Many

One of the ways to get yourself equipped with the knowledge is to read through the Salesforce Fundamentals documentation. Well, that’s how I got to it while undertaking the Salesforce Certification – Developer. However, if you find that going through the materials a hassle, you can always refer to the following explanation on a quick run-down on how to build the data model.

One to One object relationship

Scenario:
One School can only have one Headmaster

Implementation:
This object relationship requires that one of the associated object to be unique.
- School (Master object)
- Headmaster (Detail/Child object)
- Create a unique field in Headmaster object
- Create workflow to copy the School id to the unique field for every record creation

One to Many/Many to One object relationship

Scenario:
One school can have many teachers

Implementation:
- School object
- Teacher object: School field (Lookup to School)

When you view the relationship from School, it’s ONE School to MANY Teachers
When you view the relationship from Teacher, it’s MANY Teachers to ONE School

Many to Many object relationship

Scenario:
Student can enrol in many subjects

Implementation:
- This is where junction object comes into play for this relationship
- Student Subject (junction object)
- Subject (Master object to Student Subject)
- Student (Master object to Student Subject)

This model explains that there are many students taking up many subjects and vice versa.

Hope this clears off any confusion you have with regards to the object relationships.

Furthermore, if you plan to perform a Salesforce migration with other applications and require to figure out the object relationship via API, you can simply generate the Salesforce WSDL of your current instance via:

Setup > App Setup > Develop > API > Generate WSDL

From there, you should be able to determine the definition of the object relationship. The following extensions explain on the references:

__c – in reference to the custom field id values

__r – in reference to the custom object relationship with the current object view

Salesforce Integration: The 15 & 18 character alphanumeric ID

A Salesforce ID represents a unique Salesforce record. The 15 character ID comes in an alphanumeric format i.e. 0019000000CHAus.


 A simple way to retrieve this is via the URL.
A Salesforce record ID comes in an 18 character format i.e. 0019000000CHAusAAH. 
The 18 character ID is similar to the 15 characters mentioned above but appended with 3 additional characters.
The 18 character ID is only retrievable through the Salesforce API using a web service query or an Integration tool, Data Loader or Apex Explorer. Here is an example response when querying for Account records in Salesforce:
<?xml version=”1.0″ encoding=”UTF-8″?>
  <Account>
    <Id>0019000000CHAusAAH</Id>
    <Name>Abbott Company</Name>
  </Account>
These 18 and 15 character IDs represent the same Salesforce record retrieved via different mechamisms. When integrating Salesforce or using the Salesforce API, utilizing either the 15 or 18 characters ID is supported for querying or updating a specific record.

Comparing the Jitterbit Salesforce Data Loader – how does it look?

Jitterbit have just released a free data loader for Salesforce, so we thought we should check it out.

Here’s our brief analysis of the tool as compared to the Salesforce Data Loader:

Description Jitterbit Data Loader Salesforce Data Loader
Define Connectivity Supports creating multiple Salesforce connections and ability to save the connection Requires a login for every operation session (Insert, Update, Extract, etc.)
Define Operations Each operation (upsert, insert, extract, etc.) can be saved and re-used for future execution Not able to re-use previously executed operations
Supported File Formats Supports other flat file formats during insert, upsert or update operations Supports only CSV for insert, upsert or update operations
Scheduling Has a scheduling feature No scheduling feature
Retrieving or Loading Records Supports storing or loading flat files (or records) from various sources (i.e. local folder, shared folder, FTP, DB) Supports csv files from a local folder

Summary

For basic file uploads that do not require a database lookup this is a good tool.The pros for this tool are the scheduler and the monitor.   A good option for basic information uploads to Salesforce for sure.

 

 

 

 

 

 

Saasu – Company information via the API

If you are using Saasu and looking to integrate with Salesforce or a CRM that has a Company object, you’ll need to handle this differently with Saasu.  With the Saasu API you are able to create/update a Contact’s Company information via the Contact page as Company in Saasu is not a separate object.
 –> 
To retrieve or create the Company information, we can do this via the Contact Object. In a Contact profile, Saasu utilizes the following elements to associate with the Contact’s Company:
organisationName, organisationAbn, organisationWebsite
Following is an example of a insertContact Request profile which consist of the Company information (see the bold section):
<?xml version=”1.0″ encoding=”utf-8″?>
<tasks>
  <insertContact>
    <contact uid=”0″>
      <salutation>Mr.</salutation>
      <givenName>John</givenName>
      <familyName>Smith</familyName>
      <organisationName>Saasy.tv</organisationName>
      <organisationAbn>777888999</organisationAbn>
      <organisationPosition>Director</organisationPosition>
      <email>john.smith@saasy.tv</email>
      <mainPhone>02 9999 9999</mainPhone>
      <mobilePhone>0444 444 444</mobilePhone>
      <contactID>XYZ123</contactID>
      <tags>Gold Prospect, Film</tags>
      <postalAddress>
        <street>3/33 Victory Av</street>
        <city>North Sydney</city>
        <state>NSW</state>
<postCode>2000</postCode>
        <country>Australia</country>
      </postalAddress>
      <otherAddress>
        <street>111 Elizabeth street</street>
        <city>Sydney</city>
        <state>NSW</state>
<postCode>2000</postCode>
        <country>Australia</country>
      </otherAddress>
      <isActive>true</isActive>
      <acceptDirectDeposit>false</acceptDirectDeposit>
      <directDepositAccountName>John Smith</directDepositAccountName>
      <directDepositBsb>000000</directDepositBsb>
      <directDepositAccountNumber>12345678</directDepositAccountNumber>
      <acceptCheque>false</acceptCheque>
      <customField1>This is custom field 1</customField1>
      <customField2>This is custom field 2</customField2>
      <twitterID>Contact twitter id</twitterID>
      <skypeID>Contact skype id</skypeID>
      <saleTradingTerms>
        <type>1</type>
        <interval>7</interval>
        <intervalType>1</intervalType>
      </saleTradingTerms>
      <purchaseTradingTerms>
        <type>2</type>
        <interval>14</interval>
        <intervalType>1</intervalType>
    </purchaseTradingTerms>
    <defaultSaleDiscount>15.75</defaultSaleDiscount>
    <defaultPurchaseDiscount>12.50</defaultPurchaseDiscount>
    </contact>
  </insertContact>
</tasks>
For example, when creating/updating a Contact, the operation would use the organisationName value to find for matching Company Name and if there is no match, the defined Company will be created in Saasu instead.

Salesforce Tip: Apex Development – Maximum Trigger Depth Exceeded

When you are creating an Apex code that recursively fires triggers due to insert/update/delete statement for more than 16 times. You will get the Maximum Trigger Depth Exceeded error.

The following example will demonstrate this issue:

trigger cloneAnotherAcc on Account (before insert) {
Account acc = new Account(name=’Clone me’);
insert acc;
}

This trigger will end up in an infinite loop.

In order for you to solve this issue, you can set a condition on insert so it will not be called recursively. Set a flag to manage the insert trigger will be the ideal. To do this, you need to create a new class to keep track the number of times of insert or stop the insert process on second time.

global class triggerCount {
static integer runTimes = 0;

public static integer getRunTimes(){
return runTimes;
}

public static void setRunTimes(){
runTimes++;
}
}

Once you successfully create this class, you can implement this triggerCount class on your trigger to limit the number of times for insert.

trigger createAcc on Account (before insert) {

if(triggerCount.getRunTimes < 2){
Account acc= new Account(name=’Clone me’);
triggerCount.setRunTimes();
insert acc;
}
}

The RESTful JIRA 5

Recently, we’ve had a number of customers requesting us to integrate JIRA 5 with their on-premise applications (Bugzilla, Microsoft Dynamics AX and some home grown apps) or cloud applications (Salesforce and RightNow).
This is not the first time we have delivered JIRA integrations.  For our previous JIRA integrations we used the Boomi Atomsphere JIRA 4 connector that we had written, that connector uses the SOAP API.
However, the exposure to JIRA 5 is a pleasant surprise for us as it is bundled with the latest, cleaner and simpler web service – JIRA REST API.
The new JIRA REST API (https://developer.atlassian.com/static/rest/jira/5.0.html) has made our life easier as now we have more flexibility in accessing or updating the data in JIRA remotely.  In addition the performance is far better than the deprecated SOAP API.
The REST API Browser (RAB - https://developer.atlassian.com/display/RAB/Overview+of+the+Atlassian+REST+API+Browser) allows us to understand the REST operations available in JIRA better. We can  run the test using RAB against our customer development sandbox before deploying the integration into production. This helps to save the customer’s resources and reduce the risk when the integration goes live. If you want to know more about RAB, you can try it out by installing the Atlassian Plugin SDK (https://developer.atlassian.com/display/DOCS/Atlassian+Plugin+SDK+Documentation).
Another useful tool that we used in our integration development is the JIRA REST Java Client (https://studio.atlassian.com/wiki/display/JRJC/Home). Oh yes, you might find this helpful only if you are familiar or in LOVE with Java :D

Dynamics GP: The Customer Priority parameter is invalid

An existing working integration to Dynamics GP resulted in the following error when attempting to update a specific Customer record in Dynamics GP:

Status Message: cli.Microsoft.Dynamics.GP.eConnect.eConnectException: Sql procedure error codes returned: Error Number = 6328 Stored Procedure taUpdateCreateCustomerRcd Error Description = The Customer Priority parameter is invalid: 1 to 100 are valid values.

Details on the integration:

  • Dynamics GP 2010, SQL Server 2008, eConnect 11/2010
  • The integration wasn’t using or passing the Customer Priority parameter
  • This Customer record had been previously updated successfully by the integration
  • This specific Customer caused the error, different Customer records could be updated without error

Analysis of the Customer record in GP showed that the Priority field was blank, Cards > Sales > Customer > Priority:

Anyone familiar with Dynamics GP, will know that the Customer Priority field is a dropdown and that blank is not a valid value for this field:

The solution was to edit the Customer in Dynamics GP and select a specific value from the dropdown box and save the customer record.  Everything worked fine after this so we concluded that a blank or invalid field was previously in the database for this Customer, causing the integration to fail.

New Boomi feature – Document cache

Today Dell Boomi released a great new feature – Document Cache. 

You can configure a cache on any profile (say a Flat File of all your accounts). You can read in that file in one branch and map it to the cache, and set a key, say account ID.

If for example, you have a process that reads an order from a database or an app such as salesforce.com, you can, in the map step where you are mapping that, add the Cached Data, choose which field in the Order profile to link to the Key in the Cache (Account ID) and it will bring in that profile into the source map.  You can then map directly from any of the Order, or matched Account profiles to your target.

Nice.