Boomi: How to query deleted record in Salesforce

In some situation, we may need to find out what records are deleted in Salesforce, and update the status of the record in another end.
We can either do it manually which is the tedious way, or by the integration using Boomi via API.

For example:
We have two Contact records that have been removed, and they are kept in the recycle bin in Salesforce.

Let’s say we only want to retrieve these deleted records in Boomi.

To achieve this, we will can make some changes in the operation of the Salesforce connector.
1. Check the ‘Include Deleted’.
2. Add filter ‘IsDeleted’ Equal To.

3. In the connection paramater, just set a value ‘true’ for the ‘IsDeleted’ field.
Finally, we will retrieve the the deleted Contact records in XML.

Also note that, the deleted records are kept in Salesforce for only 15 days.

 

Why Boomi Advanced Workflow? Part 1: The Business Rules Shape

In this blog, we will talk about one of the powerful Advanced Workflow components, the Business Rules shape. This component is capable of simplifying your integration implementation logic by performing multiple business requirement checking prior to processing a valid document.

The integration process needs to precisely reflect the business logic, hence, the Business Rules shape. The Business Rules also has the flexibility of allowing multiple decision checking.

Let’s form a scenario for further illustration:

A developer would like to insert the Contact information from a .csv file into Salesforce Contact. Some of the fields in the csv file is empty and this may cause an error during the insert process. Below are the conditions that need to be met:

  • firstName cannot be empty
  • lastName cannot be empty
  • email must end with wdcigroup.net domain

Based on the above scenario we can easily achieve it by using 3 Decision Shapes.

This process looks a bit complex and repetitive right? We already have such a complex process with only 3 conditions let alone adding 10 or 20 more conditions? The process is going to be very long and messy. Using the Notify Shape is not a problem but it only deems to be inefficient to repeat all the steps for every condition that needs to be verified.

Luckily, Boomi came out with the Business Rules Shape component! It reduces the pain for developers while creating the process. Let’s see how simplified and efficient the process look like with the Business Rules Shape component in place.

By using the Business Rules:
  • Development can be faster, tidier and easier to maintain.
  • Provide Rejected Message within the component (saves up additional component)
  • Allow configuration of input data before verification

Hope this will benefit your design for any of the integration processes that you develop!

QuickBooks Integration: Retrieving Custom Field Values in qbxml

QuickBooks allows us to create custom fields. Sometimes we are required to retrieve the custom fields in the integration process.

So how do we want to get the custom field values out of an object using qbXML?
We will need to set the OwnerID to 0 in the request.

For example, we perform an ItemServiceQuery request with the following request:

<?xml version='1.0' encoding='UTF-8'?>
<ItemQueryRq>
  <ListID>80000031-1314102902</ListID>
  <OwnerID>0</OwnerID>
</ItemQueryRq>

In return, we will receive the following response including the custom fields and their values:

<ItemQueryRs requestID="2" statusCode="0" statusMessage="Status OK" statusSeverity="Info">
   <ItemServiceRet>
      <ListID>80000031-1314102902</ListID>
      ...
      ...
      ...
      ...
      <DataExtRet>
         <OwnerID>0</OwnerID>
         <DataExtName>Category</DataExtName>
         <DataExtType>STR255TYPE</DataExtType>
         <DataExtValue>Delivery</DataExtValue>
      </DataExtRet>
      <DataExtRet>
         <OwnerID>0</OwnerID>
         <DataExtName>Region</DataExtName>
         <DataExtType>STR255TYPE</DataExtType>
         <DataExtValue>Europe</DataExtValue>
      </DataExtRet>
   </ItemServiceRet>
</ItemQueryRs>

Boomi: Recursive Connector Call to Handle Pagination

Hello everyone! In this blog, I’m going to show you how to do recursive connector call in Boomi to handle pagination.

This is useful when you have a source system that returns the result in a batch with a fixed number of records in a single API call instead of all records. For example, the source system only returns the first 100 records out of 2000 records in the first API call. In order to get the next batch (or next page of result), you have to do another API call. Sounds easy right?! But, how can you achieve this in Boomi?

There are few steps to implement the logic:

1. create an incremental counter (increase by 100 or more – depends on the batch size of the source system)
2. create a property to hold the number of total record
3. use a decision shape to compare the counter with the number of total record to find out whether there are more records to query
4. connect the last shape to the connector shape to do the next call if necessary

Figure 1 illustrates the recursive logic in the process

When you execute the integration process, you should see something similar shown in Figure 2. As you can see in the process logs, there are 1239 records inside the source system. The HTTP connector will query 100 records in a batch until the last batch.

Salesforce Data Deduplication – Part 2

In part 1, we talked about how to de-duplicate the existing data in Salesforce.

Here, we will focus on how to prevent users from entering duplicate record into Salesforce. For example, we are going to create another record in account called ‘Test 1′ and Billing State equal to ‘Sydney’. Salesforce wouldn’t able to identify this as a duplicate record. This is because the Id of the record is generated automatically. However, we can use DupeBlocker to maintain our data.

Let me brief you on how this DupeBlocker works. First, we need to create a Scenario and insert all the logic or rules of duplication into it. Simple right?

The figure below shows on how to create a Scenario. In order to create a Scenario we need to insert the Scenario Name, Scenario Type and most importantly Match on Insert and Update Action. This is to identify the action once duplicate record is found.

There is a ‘Rebuild Needed’ checkbox, on Figure 10. This check box will be ‘checked’ automatically when a rule is created or updated. Once it is ‘checked’, we have to rebuild it by clicking on the ‘Rebuild Scenario Key’ highlighted in Figure 11.

The Rule in DupeBlocker is used to specify the criteria of a duplicate record, which means, it only compares the selected field. Duplication of newly inserted or updated record will be identified. The figure below shows the rules for the DupeBlocker. There are three additional searching algorithms available:

  1. English Fuzzy – checks the alphabet sequence in the words. It is very suitable for checking misspellings and typos.
  2. AlphaClean – analyzes the 26 characters of the English alphabet, numbers 0-9, space and &. Any other character that the field may contain will be ignored.
  3. Transpose – matches all words in a field regardless of their order.

For Figure 12, it shows that Account Name will be used to identify the duplication. Record duplication is identified once a similar Account Name is created or updated.

For Figure 13, it shows that the rule is created successfully and we can add in more rules on a scenario.

As stated at the beginning of this blog, once we have created or updated a rule we need to rebuild the scenario key.

Okay, we have done the DupeBlocker configuration! Let’s do some testing.

First, I will go to Salesforce account to create another record with Account Name equal to ‘Test 1′. Upon saving the record, DupeBlocker will show this message on the record. This confirmed that the configuration is behaving as expected.

Salesforce Data Deduplication – Part 1

Data duplication can be a hassle for the users and sometimes we would not know it is exist. However, we can use DemandTools to solve this problem. DemandTools is designed for cleaning existing salesforce data. In this blog, we will look on how to clean up the data by using DemandTools. Standard Account object will be used for testing.

In Figure 1, we can easily recognize that there are two duplicate records(highlighted). After the clean up process, both of the duplicate records will merged into one record.

Now let’s start our cleaning process by using DemandTools ‘Single Table Dedupe’ function shown in the figure below.

In order to run the ‘Single Table Dedupe’ function, we need to do some configuration. First we need to create a ‘Scenario’, followed by ‘Matching’ process and ‘Results Grid and Merging’ process. Let’s start by creating a ‘Scenario’.

From Figure 3, there are two methods to select an object.

  1. Firstly, let’s look at the ‘Scenario’ section on the left panel. We called it as pre-build scenario, which provides the readily created method or fields.
  2. Secondly, create our custom scenario from the drop-down list.

The difference between these two methods is, item #1 has limited object to select and incapable of displaying custom object. In this case, we will use #2 to select the object from the drop-down list.

Next, we will proceed to ‘Matching’ configuration. Here, we will need to specify the criteria to find the duplicate records. Okay, what does that mean? In a way, it means that we will need to specify the fields to define the duplicate records in salesforce.

For example, I have 2 records in salesforce Account object, both of them have similar account name. So, I need to specify the ‘Name’ field in this ‘Matching’ section, which helps me identify all the duplicate ‘Name’ data in my salesforce account database. The figure below shows how I configure the ‘Matching’ on a step by step basis.

1. Click on the ‘Add Mapping Condition’ button to add matching fields.
2. Select the search algorithm(Fuzzy, Transpose & AlphaClean). Easy right?

3. Go to ‘Results Grid and Merging’. In this step, demandTools will return two duplicate records shown in the figure below. The fields displayed came from the fields that we selected in the ‘Scenario’ step. Fortunately, DemandTools also provides the capability to add more fields functionality in this step. Therefore, we do not need to go back to the previous step and redo everything just for the sake of adding in more fields. What you can do is, just go to the ‘Grid Setup’ shown in Figure 6, and click on ‘show more field’ button.

4. We need to define which field to merge. First, right click on the ‘Duplicate Key: astrl_ns_tst’ and then select ‘Setup Cutom Merge’ shown in Figure 7.

Yes, you can also double click on the ‘Setup Custom Merge’ field to decide which fields and record to be retained.(Please set the record to Master to keep the record). In Figure 8, the shown fields will be merged and the master record will be retained.

We are almost finish.

5. Now, once we have decided which record and field to keep then click on the ‘Accept’ button on ‘Setup Custom Merge’ window.
6. Lastly, click on the ‘Merge Checked Records’.

Yeah, we are done!

Let’s go back to Salesforce. Now you will only find the record Id ’001G000000qHdSB’ exist and we have the Phone, Fax, and State/Province merged correctly.

Integrating to Salesforce

URL www.salesforce.com
Description Cloud CRM
API Yes http://www.salesforce.com/us/developer/docs/api/index.htm
Trial Version with API Access Yes
Protocol SOAP, REST
Data Format XML
Authentication Requires Username, Password and Security Token
API Limits  API requests per 24-hour
Developer Edition:                           5000
Professional and Enterprise Edition: 1,000,000
Unlimited Edition:                            Unlimited
For detailed information: http://ap1.salesforce.com/help/doc/en/integrate_api_rate_limiting.htm
Sample Use Case Salesforce Account > create/update > Netsuite Customer
Salesforce Contact > create/update > Netsuite Contact
Netsuite Product > create/update > Salesforce Product
Salesforce Opportunity > create/update > Netsuite Opportunity
Netsuite Invoice > update > Salesforce Opportunity
 F2I  4.9
 API supported objects   http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_list.htm
Objects/Operations
 

Salesforce Tip: Monitoring Time-Based Workflow

Ever wonder if there is a way to monitor the outgoing email queue triggered from the Time-Dependent Workflow?

1. Go to Setup > Administrator Setup > Monitoring > Time-Based Workflow
2. After that you will see a search page. You can do a search of the email queue by filters or search all of them. You will get the list of email queue from the search result.
3. Another thing you can do here is to delete any email queue that you want so that it will not be sent out.

Boomi: Map Functions Ordering

Recently, Boomi has introduced a new feature in the map: Map Functions Ordering.

This feature is very useful as it allows us to control the sequence of which map functions to be executed to achieve the desirable result. Here is a simple scenario.

Imagine we have this set of data and we would like to calculate the total amount in the maps steps.
Line No,Amount
line 1,20.50
line 2,30.50
line 3,40.50
To achieve this, we will create two map functions:
1. calculateTotalAmt user defined function – this will calculate the running total and store the value into a user defined document property called “totalamount”
2. get user defined document property function – this will retrieve the value stored in step 1
Figure 1: Map step in Boomi
By looking at it, the process should return me 91.50 as the total amount. But the reality is the process will return me empty result instead. This is because Boomi will return me the value of “totalamount” user defined document property first before it is being set in the calculateTotalAmt user defined function. To overcome this problem, we can enable the Map Functions Ordering by clicking on the “Order function executions” icon shown in Figure 2 and check on the “Enabled map function ordering?” checkbox.
Once it is enabled, we can move the calculateTotalAmt user defined function to the top and click Ok to save the ordering.
Now try to run the process again and it should return 91.50 as expected.

Oracle RightNow CX Object relationships explained

Understanding object relationships and the data model in RightNow is helpful when it comes to RightNow integration. Object relationship enables you to implement your business complexity in RightNow by relating standard objects with any custom that are required for your business.

When integrating with RightNow, understanding the object relationships is beneficial when designing the integration process such as determining the parent and child relationship as well as the logic to handle any deleting of records.

Why bother about object deletion? The behavior of record deletion is dependent on the type of relationship used.

In RightNow, the following three relationships are emphasized:-

  1. Aggregation
  2. Association
  3. Self-referencing

Some further details The following section, further defines the relationships and its possible use case which you can use as a reference on how to build a data model which suits your needs in RightNow.

Aggregation

This type of relationship is used when you want objects to be tightly relate with one another where the child objects will be deleted along when the parent object is deleted.

Scenario: When you have bug/incident records that is tie to certain product range in your business, you may not want to keep the related bug/incident records anymore in your RightNow system when the product is no longer available or obsoleted. In this case, you can utilize the aggregation relationship to link a custom bug or standard incident object as the child to the sales product or a custom product object which you implemented. Once, the product is deleted, the child records will be deleted as well.

Association

Consider using this when you want the objects to link/reference with one another but not tightly related. This relationship will not deletes the child object automatically when the parent object is deleted.

Scenario: When you have bug records that is linked/related to an incident raised by your customer. You only want the bug to link or reference with the incident raised instead of strongly tying the bug with the incident so that when the incident is deleted, the bug record is still available in your system for others to reference. To achieve this, you can utilize the association relationship to link up the child custom bug object and the standard incident object in RightNow.

Self-referencing

This relationship applies only when you have objects that utilized the association relationships and can be configured by linking the child and parent object of itself.

Scenario: You may have an umbrella or a pool of related bug/incident being tracked in your system. You would want the bug/incident to reference one another under a parent bug/incident which has been raised for the same topic. In this case, the child and parent objects would be the custom bug or standard incident object itself.

Hope this gives you some idea on how should you customize your RightNow instance to suits your business needs as well as some consideration when integrating your RightNow and other applications. For more information related to custom objects and defining relationships, please see the RightNow CX User’s Guide.