We are hiring a Salesforce.com specialist. If you or your friends are interested, check out our advertisement here:
Ever wonder if there is a way to monitor the outgoing email queue triggered from the Time-Dependent Workflow?
eConnect is a medium that allows integration between Microsoft Dynamics Great Plains (Dynamics GP) with other applications. The following are some information related to eConnect:
- provide programmatic access to Dynamics GP data
- uses XML documents for data communication
- implemented as a set of database stored procedures installed on the Dynamics GP database server
- the stored procedures ensure that the data import are valid and compliant with Dynamics GP
For detailed information about eConnect:
In order to configure the integration between the applications, the eConnect connection needs to be established with the application’s underlying database – Microsoft SQL Server. eConnect stores the available objects that can be executed on. One should be able to retrieve/send data from/to Dynamics GP based on the supported objects.
Note that this list has the corresponding physical table name for the objects as well as the associated fields. For example:
The Cash Receipt object is referenced as table name: RM10201 within the database
In our work of integrating with Dynamics GP, most of the object queries are supported in eConnect. However, there were also times where eConnect does not support every object query and send method that we need. Hence, when there is a need for more advanced queries, one of the options is to:
1. insert a new row into eConnect_out_Setup and specify the table/trigger to use
2. create stored procedure to link with the records
To identify the corresponding table, see:
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 School can only have one Headmaster
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 school can have many teachers
- 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
Student can enrol in many subjects
- 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
Getting the product stock quantity in Magento is a bit tricky as you can’t get it from catalog_product.info API call.
- array products – list of products IDs or Skus
In the Pearson application there are 2 types of authentication methods, oAuth1.0 and oAuth2.0.
Pearson LearningStudio API supports both OAuth 1.0 and OAuth 2.0 authentication methods.
When building an integration to communicate with Pearson LearningStudio we used the OAuth 1.0 module. Here is an example of how to get the authentication working:
1) Prepare all the required credentials:
2) Generate the timestamp. You should convert current time to seconds.
long timeStamp = new Date().getTime()/1000;
3) Generate nonce, a random alphanumeric string. You can only use numbers or letters, you can’t just use letters. This nonce needs to be unique per request. Any duplicate nonce value will be rejected. The nonce must not exceed 32 characters.
Random nonceGenerator = new SecureRandom();
// Any number between 0 to 999999999
long nonce = nonceGenerator.nextInt(999999999);
4) Prepare the signatureBaseString.
// Method such as GET or POST in upper case
String method = method.toUpperCase();
// Prepare the resource path and encode it
String resourcePath = “/courses/10000″;
String encodedResourcePath = URLEncoder.encode(resourcePath, “UTF8″);
// Make sure that this string is URL encoded. For example ‘=’ is encoded to %3D
String signatureBaseString = method + “&” + encodedResourcePath + “&application_id%3D” +
applicationID + “%26oauth_consumer_key%3D” + consumerKey + “%26oauth_nonce%3D” + nonce + “%26oauth_signature_method%3DCMAC-AES%26oauth_timestamp%3D” + timeStamp;
5) Prepare the signature by signing the signatureBaseString with the consumer secret.
6) Use Base64 to encode the signature to produce the encodedSignature.
7) Once it’s ready you can use it to build the X-Authroization header using the follow format:
String authHeader = “OAuth realm=\”" + baseURL + “\”,oauth_consumer_key=\”" + consumerKey + “\”,application_id=\”" +
applicationID + “\”, oauth_signature_method=\”CMAC-AES\”,oauth_timestamp=\”" + timeStamp + “\”,oauth_nonce=\”" + nonce + “\”,oauth_signature=\”" + encodedSignature + “\”";
We have just developed an integration process between Microsoft Dynamics GP and Salesforce. An integration with Dynamics GP is a bit tricky as it utilises the eConnect layer to integrate. Interested in more details? Check here for more information!
One of the tools we use to build integration is Talend. Talend is an open source integration tool.
When you are building the Salesforce integration, one thing we need to take note is the maximum size of the request per batch to Salesforce. The maximum size per request is 52428800 bytes. If that exceeds the limit, you can split the request into different batch.
BusinessCatalyst-MYOB ReadyMade is back due to popular demand.
The new release creates MYOB Item Sales Invoices and Customer Cards from Business Catalyst website orders.
You can run it on a schedule or on-demand, it’s that easy.
This is how the data flows between Business Catalyst and MYOB:
Want to know more about BusinessCatalyst-MYOB ReadyMade V2 check out our website for details.
Let us talk about one of the common errors returned from QuickBooks integration when the integration process incorrectly modify the data in QuickBooks.
Status code: 3170: Status message: There was an error when modifying Vendors/Customers list, element “#######-##########”. QuickBooks error message: Cannot merge list elements.
Why does this happen? This will occur when modifying a Customer/Vendor record by referencing the record’s ListID and Customer Name, however, there is already an existing record with the same Customer Name in QuickBooks. Here is an scenario to explain this error:
We have an integration process between the QuickBooks and Salesforce where we can sync the Customer/Account from/to QuickBooks to/from Salesforce.
1. There are 2 customers in QuickBooks.
- Customer Name #1: Tony Adam; ListID: 1234567-1234567890
- Customer Name #2: Ronald Williams; ListID: 2345678-2345678901
2. These 2 records have been synced to Salesforce and they are created as Account records with the ListID as external ID.
3. User modified Customer #1 in Salesforce. The customer name is changed to Ronald Williams (same as Customer #2).
4. Customer #1 is being synced into QuickBooks via API and it tries to update the customer by the ListID. However, QuickBooks blocks this operation as it found that there is already an exsting recod found (Customer #2) with the same Customer Name but different LISTID. Hence, Customer #1 failed to be updated into QuickBooks.
Note: Customer Name must be unique in QuickBooks, this is to avoid duplication in customer records.