BizTalk360 is a browser-based monitoring application for Microsoft’s BizTalk integration platform. The out-of-the-box monitoring functionality can be difficult to navigate both for new users and experienced admins, and is complex and time consuming to set up for multiple users with varying access rights. BizTalk360 combines the Admin Console and Event Log, with some added analytical and notification functionality, to create an easy to navigate operational tool.
In this overview of basic BizTalk360 setup, I will assume you have a BizTalk application already deployed that contains at least one receive port and send port. Although there is a huge amount of configuration and monitoring that can be done through BizTalk360, this article will focus on initial configuration and simple environment health monitoring.
While testing an integration it is always important to perform a series of negative test cases to ensure the process can fail gracefully through error handling. It is not always possible for endpoint environments to be set up for quick and easy testing. For this reason, a useful step in the development process is to create test harnesses. These can act as the implementation of abstract test cases beyond simple shape-to-shape testing. Test harnesses are also incredibly useful for regression testing.
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 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?
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…
Using NetSuite Custom Segments in Boomi
Part 2: Retrieving Custom Segment Data with SOAP Request
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…
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…