The definition of a pattern is "a general reusable solution to a commonly occurring problem within a given context in software design." At Jitterbit, we recognize that there are common integration problems encountered by our customers that can be solved by using our software. By identifying the patterns and providing real-life examples, we hope to provide a resource to customers who understand their integration scenarios, and who want guidance on how to implement them.
For example, a common scenario is querying a source and updating a target. We identify numerous patterns that support that scenario, such as querying using a timestamp, using the value of a field, or using a file. Moreover, once the records are retrieved, there are common patterns where the records are acted upon conditionally, or one record triggers multiple actions.
The main use of integration patterns is a guide to the Jitterbit user who is familiar with how Jitterbit works and its functions, and is looking for help on how to tie it all together to solve their integration scenario.
A pattern is not a pre-built Jitterpak, a step-by-step how-to (such as importing a WSDL), or documentation of a specific function. Rather, a pattern illustrates an integration problem that many customers may encounter accompanied by the Jitterbit solution.
The example may not be perfectly applicable to the customer's environment. If an example uses SAP, but the customer uses a database, that does not mean the pattern does not apply. A query using an SAP BAPI vs. a query from a database table is not so different from a pattern design perspective. The important point is to identify a pattern that applies to your integration scenario, understand how it is implemented and adapt it to your specific environment.