In most scenarios when a lookup is required (transforming a value from source to destination, example code “T” from source is transformed to “True” to destination) the Cross Reference Lookup is being used, a great lookup that provides multiple references that can be reused throughout the process or among processes within the same account.
Recently we noticed that there is a new lookup, Simple Lookup, and as the name suggests it provides a simple two column matrix.
Boomi allows us to create a new XML profile by importing from a XML Schema. However, it can only support the common XML schema, XSD. So, what to do if you only have DTD schema? One quick solution is to convert the DTD to XSD by using the free conversion tool that is provided by W3C.
Once you have generated the XSD, you will just need to import it into Boomi.
Certain products that are up for sale require product activation code. In Salesforce, a custom object is created to store all the product activation code records. Whenever an opportunity is closed won, the opportunity products should be assigned with activation codes and details. This can then be generated out in PDF form and sent to customers. There are a series of filters and criteria involved when it comes to assigning the right activation codes to the right opportunity products and this process is currently being handled manually. User will have to eyeball both the opportunity products and activation codes to link them appropriately. It is pretty time consuming when you have to manually assign these activation codes to the opportunity products when the list is long (e.g. 10 products and above).
We have implemented Visualforce page and Apex classes and to do the following:
1. Page to list out all the opportunity products that require product activation codes (exclude the product that do not require activation codes).
2. Apex class to search for available product activation codes from a different object based on specific criteria.
3. Apex class to link both the opportunity product and the product activation code together and populate relevant product activation code data to product and vice versa.
||Apex Classes, Visualforce Page
There is a flag in most of the Boomi connector send operation called “Return Application Error Responses”. If this checkbox is checked, Boomi will return you the Error Document (e.g in XML format – depending on the target application) as a response so that you can have do additional error handling logic after the send operation. Please see Figure 1 for an example.
Figure 1: Sample process flow
However, not every connector will have the response profile generated automatically during the import. For example, if you look at the Web Service SOAP Client connector, it will generate 2 profiles: Request Profile and Response Profile automatically during the import. But, for a connector like Salesforce, it will only have the Request Profile. So, how can we get the Response Profile? One easy way is to:
- run the process in test mode
- retrieve the shape source data by clicking on the shape (e.g, in the example above, it will be success decision shape) after the send operation
- save the data into a text editor
- create a new profile in Boomi and import the saved text file as the profile schema
Tada! Now you can use the newly created profile as the Response Profile for the connector send operation.
In integration, sometimes I will encounter a situation whereby I need to post a data to a HTTP endpoint as a query string in the URL. However, this will not work correctly if the data string is too long (there is limit in the length of HTTP request URL). To get around this, I have to post the data as a form. Here, I’m going to show you how you can do this in Boomi:
1. write a custom scripting in a Data Process shape to encode the data (java.net.URLEncoder)
2. use a message shape to construct the param and set the current data (URL encoded in Step 1) as the value
3. set the HTTP Post Operation content type as “application/x-www-form-urlencoded”
This will be the final outcome:
The last thing that you will need to do is to run the process.
This agency helps their partners to market their products to hypermart. The challenges they have are:
- The agency sales rep needs to keep track of the historical purchase for each hypermart. They are unable to share this information with their partners.
- When the agency sales rep receives an order from hypermart, they will need to place an order to their partners. This is currently done via phone call.
- The agency sales rep should also monitor the shipment of the purchase to hypermart. It is tracked in a spreadsheet.
- The communication between 3 parties are all in email/fax format. It is time consuming to consolidate them.
Salesforce Partner Community via the following setup:
- The partners can login and access to their Salesforce with restricted access to their own data.
- The partners can view all new/historical sales from different hypermart
- All communication (email/call) is tracked using Salesforce activities
- The full life cycle from Lead > Sales > Shipment is tracked in Salesforce. This process is also visible to the partners.
||Opportunities, Shipment, Order
||Partner Community, Report, Dashboard
Some connectors (ex. Salesforce, Netsuite, etc.) can be configured to retrieve the data in either per document or in a batch results.
‘Batch Results’ is batching all result documents into a single list document. There is one important note to take to get a successful list document. After you have done with the profile import, the imported profile (see attached screenshot) is only able to store single document data and not the documents in the list.
If you are getting the data into Map transformation step, you will need to a create a custom ‘list’ XML profile to pass through the data. If not, you will get the “No data produced from map…” error.
To do is to manually create a new ‘list’ XML profile. Basically is to move all the elements of the onto one level lower (as shown below) and set the ‘Max Occurs’ of the second level Element to ‘unbounded’.
In this blog, we will look at how Boomi handle an error execution of a sub process and how it affects the parent process. Let’s separate this into 2 categories: Synchronous and Asynchronous Execution
As we all know that a Data Passthrough sub process will accepts the document from the parent process. In this, if there document failed in the sub process, it will also stop the parent process with error regardless of the “Abort if process fails” option.
No Data/Connector Call
If the “Abort if process fails” option is enabled, the sub process will fail with error. The parent process will also failed with error and it will stop at the process call shape (where the sub process is being called). However, if the “Abort if process fails” option is disabled, only the sub process will be error-ed.
Figure 1: Error Log for Synchronous Process
This is not supported in asynchronous execution
No Data/Connector Call
If the “Abort if process fails” option is enabled, the sub process will fail with error and this will be reported back to the parent process. And, the parent process will be flagged as error only after the parent process has finished executed all the process paths. Please see Figure 2 for the sample error logs.
Figure 2: Error log for Asynchronous Process