Through the use of Atom Queues and Listeners a single process can spawn many iterations of a listening process. Each process spawned from a listener will execute asynchronously, independent of any other executions. By default, an Atom Queue listener will spawn an instance of the listening process every time a document is written to the queue. While this will work fine in cases with a low throughput, larger numbers of documents being processed will cause a large number of executions to get kicked off.
Many times when working with Microsoft Azure, it is necessary to read and write information to Microsoft Azure File Storage. Unfortunately, at this time Dell Boomi currently only supports a Microsoft Blob Storage Connector; one possible solution to this problem is to use Microsoft’s AzCopy utility to read and write information to Microsoft Azure File Storage.
AzCopy is a command-line Utility designed for copy data to and from Microsoft Azure Blob, File, and Table storage; but our purposes we will be using it to write data to Microsoft Azure File Storage.
AzCopy can be downloaded from this link (http://aka.ms/downloadazcopy). To install, simply follow the installation instructions.
One possible use of AzCopy is to upload newly created data files to Microsoft Azure File Storage. By doing so we can call AzCopy to upload the data files after we have finished creating them all rather…
Many times when a document cache is created for use in a lookup function, only a few values are actually needed. A typical approach to document caching would write an entire document to the cache, including unneeded values. This approach works fine when caching a small number of documents, but will perform worse as more documents need to be cached. A much more efficient approach is to only cache the elements of a document that are actually used.
Once a process is deployed, any debugging or error tracing is typically done through the process logs. Although this method of debugging answers where in the process and error occurred, the developer lacks the answer to a crucial debugging question: “What data caused this error?” In test mode, a developer can simply look at the Shape Source Data of the component where the error occurred. After deployment, that level of granular debugging is not present. So how can we see the documents that were passed through the process?
Setting Verbose mode for a Boomi Process using a Dynamic Process Property
In most instances developers will have to accommodate certain reporting, notification and logging requirements of a given interface within the Dell Boomi AtomSphere platform.
Often times, the logging or emailing may need to be disabled for testing and/or faster iterative cycling through test cases and, of course, to not annoy the user community with email test messages.
The most straightforward way to accomplish or implement a verbose or Test Mode Boolean flag (as is very common in other platforms) is to create and enable a Dynamic Process Property and then assign its default value while allowing to reassign the same with extensions directly after deployment.
Dell Boomi provides the concept and implementation of extensions to allow developers and administrators to have distinct values for different environments without having to use multiple connectors of the same type.
As an example in a given scenario where a Dell Boomi Process uses a disk connector to read a file but the file location changes from environment to environment.
1. Test Server file folder location: C:\TEST\Inbound
2. QA Server file folder location: C:\QA\Inbound
3. Production Server file folder location: C:\PROD\Inbound
Although Boomi’s standard NetSuite connector can implement filtering within the connector itself, relying on saved searches to implement filtering is a much more robust design pattern.
The out-of-the-box NetSuite connector implements parameterized filtering that will be included in the request sent to the NetSuite endpoint. This filtering is useful during testing or in cases where the number of records being queried. However, a more robust and abstracted method of filtering is to make use of NetSuite Saved Searches. This methodology also allows NetSuite users to take ownership of their data, instead of relying on developers to make changes to filtering.
This eliminates the need for excessive filters in the connector itself. If at any point the filters in a native NetSuite connector need to change, the interface would have to be redeployed. This could become tedious and error prone. A Saved Search…
Due to limitations in the NetSuite API which Boomi utilizes, Custom Segments are unable to be returned from a standard connector shape. A profile imported with Boomi’s standard NetSuite connector and operation will not contain any Custom Segments. To work around this, a SOAP connector is needed in order to send a modified HTTP request that includes requests for the custom segment.
The examples in this tutorial will being using the Inventory Item base entity in NetSuite to show the use of item level custom segments. The principles in this tutorial could be applied to any NetSuite entity.
Two shapes are needed to replace a NetSuite connector in a Boomi process: a message shape and a SOAP connector. The HTTP request will be set in the message shape. The SOAP connector will require a connection and operator with two SOAP profiles. The…
Using NetSuite Custom Segments in Boomi
Part 1: Importing Custom Segments to Boomi Cross Reference Tables
Due to limitations in NetSuite, custom segments are not available to choose as results in saved searches. This limitation requires the custom segment data to be retrieved using a SOAP connector with the custom segments explicitly requested instead of a normal NetSuite connector.
Custom Segments can be viewed by navigating to Customization > List, Records, & Fields > Custom Segments. Or by searching for “Custom Segments”.
Custom segments are comprised of ID/Value pairs. More information can be applied to these values, such as hierarchy and active/inactive flags, but a simple Custom Segment will be used in this example, shown below.
The values themselves will not be returned by NetSuite, and the IDs are not very useful in and of themselves. The IDs that are returned will need to be…
The Dell Boomi local atom installation directory has within it a number of executables, jar files, logs and settings files, and this post is meant to help a newcomer be able to navigate their way around this collection of files. We plan on targeting a few select folders ( highlighted in the image below) for discussion, because these are the folders that have the files we most frequently need to touch.
This directory contains files that are used by the installer when first installing the atom to your computer, but besides that there are a couple of files that might be of interest to someone after installation is complete. The inst_jre file contains a single file path which points to the jre that was used during the installation process. The installer itself is a java application and therefore needs a jre to be installed on your…