Navigation made easy with Lead Notifier

It’s that time of the year when the air is full of performance reviews. Appraisal cycles are in full bloom and the managers are on a prowl! Every employee is seen making his best attempts to impress his manager, hopeful of getting a bigger chunk of the delicious pie called performance bonus and I was no saint either! But impressing my manager was no easy job! What is it that I could do? I probably needed something as path breaking as a time machine!

Introspection…Innovation…Impression…

I thought and thought hard. I realized I had the power of Salesforce and I felt like a rock star! My plan was beginning to shape up now. Let me give you a sneak peek!

I realized that most Sales Reps in my organization ended up spending a huge chunk of their time navigating back and forth, from their Salesforce screens to monitor the new incoming Leads. This navigation was a big no-no as far as productivity was concerned and monitoring new leads was becoming increasingly difficult for them. “Why is that a big deal? You have Queues, Assignment rules and emails for Lead Management!” I hear you say. However, ours was a Salesforce instance that had just started out. And I needed to do something about it!

The Game Plan!

My game plan was built on a simple fact: The user should be notified whenever a new lead is generated, irrespective of which tab he was navigating on: home or elsewhere within the application.

The solution involved using a combination of Apex and Visualforce but the secret component of my solution plan was to leverage the Home Page and Sidebar components. Let me show you how I did it in a few simple steps!

1. First, I created a simple Visualforce page using the code snippet given below. I call it the Lead Notifier Page.
   
   
   
   Apex Code
   
   
   

   Visualforce Code
   
   The Visualforce code leveraged the standard < apex:actionPoller > which enabled auto refresh, thus facilitating the lead notifier to pick up the newly created Lead information in real time.
   
   
2. Once this was done, I modified the home page component and added the Lead Notifier Page created in step 1, so that it started appearing on the Home page.
   
   
   
   
   
3. I went on to modify the sidebar component to add the Lead Notifier Page created in step 1, so that it started appearing on the Home page.
   
   
   
   
   
   
   
   Finally, this is how my Home page looked like.
   
   
   
   
   

There! I had nailed it! My Sales Reps were absolutely loving it! Needless to say, I got a few brownie points from them when they put in a favourable word to my boss. As for me, I was simply glad I had Salesforce to rely on, no matter what!




Written by Jigar Shah, Solution Architect at Eternus Solutions

Read More »

Topic-based Publisher Subscriber Design Pattern

When it comes to design, I have a pretty simple philosophy: set up something that is generic and reusable. But design patterns sound way easier than they actually are. It is like setting up the electricity wiring for your newly built house. You know that you need approximately 200 Amps of electricity, but actually setting up the wiring is altogether a different ball game. Like I said, deep diving in the sea of design patterns was not an easy task. Thankfully, I came across the Publisher Subscriber Design pattern, which is generic, easy to use and dynamic, meaning I can dynamically add anything with just a few clicks!

Publisher Subscriber Design Pattern: A Closer Look…

As far as the architecture is concerned, a Publisher Subscriber Design Pattern will generate messages for another system to consume. This chaining will go on for n levels.

1. Publisher - Publishers post messages to any message broker or queue; for topic based pub-sub model messages, belonging to a specified topic to which Subscribers can subscribe to.
2. Subscriber - Subscribers can subscribe for the messages published by the publisher system through topic based subscription via a message broker or a queue.
3. Topic Subscription - The topic subscription will hold the subscription specific details. Since the Publisher would not know its subscribers, the messages would be routed to the subscriber based on the topic subscriptions.

In short, the Publisher system is going to publish to the Message Broker/Queue where the topic subscription would already be set in. So this architecture signifies the many-to-many relationship between the end systems.

Schema Structure & Analyzed Keynotes

Before starting to put anything architecturally, I needed to think of a generic data model that would suffice for any kind of system. A single system ideally would work as a Publisher as well as a Subscriber for others.

The data model shown below leverages Event Notification Service to capture any messages that need to be published/subscribed in the form of an event.

1. System Table - This table would hold the Publisher and the Subscriber information. Each system should be associated with one unique key constraint so that this would be globally unique.
2. Topic Table - This table would hold the list of Subscribing & Publishing topics. Based on these topics, the system would either consume the message it has subscribed to or publish the message
3. Event Table - This table will be associated with the Topic & the System. This object is the entry point for data flow within the system or externally. Any operations that need to be performed within the system or outside the system will be flown through the Event table.

Generalization of Structure

1. Whenever any event records get created across any topic, the system would generate an automated process to perform the respective operation.
2. The post logic would be run either for further raising any events acting as new Publisher or respond to its respective publisher system.

Advantages of Publisher Subscriber Design Pattern

1. Scalability - It takes just a few clicks to add / remove the event subscription. Whenever you want to add/remove any system, you just need to go and update the queue table which will eventually start/stop acting as per the requirement
2. Single Point Control - Updating a single table will change the whole cycle.
3. Implementation Cost – This architecture is quite simple to implement. The structure of each system for handling the event notification structure remains the same and hence leads to considerable reduction in implementation cost.

Disadvantages of Publisher Subscriber Design Pattern

1. Failure In Message Delivery - Failure in delivering a message would cause a problem to the subscribing system in case you need the messages to be delivered in a sequence.
2. Ordering – In case custom sequencing or ordering is not implemented, the messages do not guarantee an order.

The final word…

Despite its due share of cons, I would recommend using the Publisher Subscriber design pattern, especially when you want to put a dynamic and reusable architecture and make multiple systems interact amongst each other, that too, with just a few clicks! Why don’t you give it a try and tell me how it worked out for you?




Written by Amit Shingavi,  Salesforce Developer at Eternus Solutions

Read More »

Bing Map for Microsoft Dynamics CRM using an HTML Web Resource

Thanks to its readymade SDK, Silverlight was considered as the best option to display maps on Microsoft Dynamics CRM for a very long time. However, owing to plug-ins requirement and limitations with device compatibility, developers round the globe like me were forced to look for an alternative, more suitable option. And we struck gold...with HTML5! In this post, I am going to demonstrate how to build a simple map component in MS Dynamics CRM with nothing more than HTML5 and JavaScript!

Before we get started…

You will need to have a basic idea about how to use Bing maps in HTML and decent hands-on experience of customizing MS Dynamics CRM. You will also require to add latitude and longitude fields under the Address field in Account, Contact and Lead entities.

So let’s get rolling!

Our Target

We are going to build a map for three of the most-used entities in MS Dynamics CRM: namely Account, Lead & Contact. We need to display all the records for these entities within our map.

Take a look at the image shown below where all accounts are displayed on the map in the form of Bing map pushpins, accompanied by a hover effect, which provides more details of the selected account.

This is a 6-step process:

Step 1.

Get the base URL for accessing the application data, as shown below.

Step 2.

Next, you need to create the request query for accessing the latitude and longitude of all Accounts, from the Account entity itself. I used the following Query:

Step 3.

Once you have created the request query ad demonstrated above, you need to make an Ajax call to get the actual data from MS Dynamics CRM with the help of requestUrl used in step 2 above. Pass on this result to another JavaScript function to add the pushpins on the map as shown here.

Step 4.

Once you get the data from the Ajax call, you can proceed to adding the pushpins on the map. However, bear in mind that before you start this, you must have initialized the map component on the HTML page. I have demonstrated the same below.

In the code snippet shown above, the click event is added dynamically to perform the click operation for opening the corresponding Account page directly, while the mouseover event is added dynamically to see the details of selected account.

Step 5.

Once this is done, add your all Java Script code to your HTML page, within the body tag.

As you can see above, we have added a simple HTML web resource for the map in MS Dynamics CRM. Now you need to upload the web resource to the MS Dynamics CRM and customize the ribbon, in order to access the map resource on the MS Dynamics CRM page.

Step 6.

Finally, you need to modify Step 2 for performing the same operation on Contact and Lead entities.
You can change this customization to provide a Heat map simply by just changing the map type. You can also use additional Bing map APIs to get direction or route to different entities in MS Dynamics CRM.

Use HTML Web Resources instead of Silverlight because…

• Silverlight web resources cannot be viewed in the 64-bit version of Microsoft Office Outlook
• Silverlight web resources remain supported in Microsoft Dynamics CR 2015 and Microsoft Dynamics CRM Online 2015 updates for backward compatibility. However, Microsoft recommends using HTML web resources with HTML5 instead of Silverlight for components that will be able to be presented on all clients.
• HTML5 is the preferred client technology for the web over web plug-ins like Silverlight and Flash. HTML5 can be consumed from any device, be it your PC, tablet, smartphone and much more, and heavily uses JavaScript and its powerful libraries like jQuery and CSS.

For more information, you can refer to https://msdn.microsoft.com/en-us/library/gg328358.aspx

Written by Pramod Dhokane,  .Net Champion at Eternus Solutions

Read More »

Salesforce to Amazon Integration Using Signature Version 4: Part 2

In my previous post on Salesforce to Amazon integration using Signature Version 4, I had taken you through the process of creating a canonical request, which formed the first step for calculating a signature required for the integration. As promised, I am back with the remaining steps you will need to complete for integrating Salesforce with Amazon.

Step 2: Create a String to Sign

The string to sign will include meta information like algorithm, date, credential scope and the digest that was calculated in step 1. It is calculated as shown below:

• Generally, SHA256 algorithm is used for generating digest. For creating a String to Sign, you need to write AWS4-HMAC-SHA256 instead of SHA256
• Add the request date in ISO8601 Basic format via the x-amz-date header in the YYYYMMDD'T'HHMMSS'Z' format
• Credential scope includes date(just date, not date time), the region
• The service that we are requesting and the terminating string i.e. aws4_request must be in the lowercase. The region and service name strings must be UTF-8 encoded.
• Finally, append the hashed canonical request that was calculated in the first step using the Hash function mentioned above. Your string to sign will look like:

Step 3: Calculate the Signature

For calculating the signature, you need to derive the signing key from AWS secret access key. For deriving the Signing key, you need to create a series of hash-based message authentication codes (HMACs) using HmacSHA256AH algorithm for date, region, service. You can derive the signing key as given in the code snippet below:

The sign function used for creating the HMACs is as shown below:

After creating the signature as a digest, convert it into a hexadecimal representation using EncodingUtil.convertToHex function. The final signature, after conversion to hex will look something like this:

B. Creating a Sign Request

After the signature has been calculated, you need to add it to the query string. Query string will contain the action, the action parameters, and the signing information. This request is known as pre-signed URL and it is calculated as:

The following example shows what a request might look like when all the request parameters, including the signing information, are included in query string parameters.

Before I sign off…

While integrating Amazon with Salesforce using signature version 4, you need to bear the following in mind:

1. Date information should be an eight-digit string representing the year (YYYY), month (MM), and day (DD) of the request (e.g., 20120228)
   
2. Region information should be a lowercase alphanumeric string
   
3. Service name information should be a lowercase alphanumeric string
   
4. A special termination string: aws4_request
   

There! You are now ready to conquer the world, what with both Salesforce and Amazon data at your disposal at a single location, and why not, you have it covered A to Z after all.


Reference: http://docs.aws.amazon.com/general/latest/gr/sigv4_changes.html



Written by Tejashree Chavan,  Salesforce Developer at Eternus Solutions

Read More »

Multilingual Data Import into Salesforce Made Easy

If you have been working on Salesforce for a while, you will agree with me that no matter what application you build, importing large amount of data in Salesforce comes with its own set of challenges. This problem is compounded when you need to import multilingual data, and you can only imagine the magnitude of the problem when you are importing large amount of multilingual data!

My David vs. Goliath moment

I had this feeling last week, when I needed to important approximately 60,000 records in…hold your breath…five different languages: Vietnamese, Cantonese, Thai, Japanese and Korean! These languages have special Unicode characters, making my already unenviable task even more cumbersome. Some of my peers sympathized, some even sniggered!

What’s the big deal, eh?

To say that importing Unicode characters is difficult would probably be the understatement of 2015! The normal data import process of using Data Loader or the use of native Salesforce Import/Export Wizard does not work directly in an efficient manner for multilingual data, especially for Unicode characters. You can still import data in Salesforce using either of these approaches. However, most of the Unicode characters are converted into #,? and other random characters, thereby compromising the correctness of data imported.

So how did I wade through this labyrinth?

Keep it Handy!

Before I take you through this easy 6-step process, there’s one thing you’ll need ready with you: an Excel worksheet consisting of the multilingual data containing the Asian characters that you need imported in Salesforce.

Solving the Maze

1. Save the Excel data sheet containing multilingual data as a file. For the purpose of this demonstration, I have named it Unicode Text.xls
2. Open the file created in step 1 with Notepad
3. In Notepad, navigate to File > Save As. Check if the popup shown has an option to set the ‘File Encoding’. If it does, change the encoding to UTF-8. If it doesn’t have an option that says UTF-8, then you have an older version of Notepad that doesn’t support this option. Here you would end up saving it as UTF-16 which can also be imported by Salesforce.
4. Ensure the filename has ‘.csv’ as its extension in its name and the “Save as Type” has “All Files” selected in the dropdown. Save the file.
5. Using Import Wizard/Data Loader, import the file created in step 4 into Salesforce. Select your file to Import and the Encoding in the drop down list. This could be either in UTF-8 or UTF-16 format, depending on the selection you used while saving the CSV files.
6. Check the log. Although the .CSV file was not comma delimited, Salesforce is able to import it properly. The characters now show up accurately in Salesforce.

To give you a perspective, I have included snapshots of how it appears within Salesforce with and without encoding.

Data Import without Encoding

Data Import with Encoding

What a wonderful thing encoding is, isn’t it? So go on, try this out. I am sure all those sleepless nights when your imported data turned out to be totally screwed up will be a thing of past now!



Reference: How to import Asian characters from a CSV file into Salesforce

Written by Nupur Singh, Technical Lead at Eternus Solutions

Read More »