There are a number of places throughout the application where you can specify the data type and format of a field or value. These are most common in Profiles but can also be found in formatting Map Functions and various Parameter date values.
Database Profiles are unique in that you do not need to specify a format for date and numeric values. The database itself determines the formats so Boomi simply communicates with native date or number objects.
When mapping data, formatting can be applied explicitly using Map Functions or it can be applied implicitly by defining the format in both the source and destination Profiles. For example, suppose you're mapping the "Last Modified Date" from system A in one format ("10/29/2007") to system B in another format ("2007-10-29"). If you configure the format in the Profile elements (MM/dd/yyyy and yyyy-MM-dd, respectively), the value will be translated "behind the scenes" without the need for a Date Format Map Function.
 | Tip Configure date and number formats in the Profile to eliminate the need to use multiple Map Functions in a Map for formatting. |
Character

There are no formatting options for character or string data. If the data doesn't need to be reformatted during mapping it sometimes can be easier to leave all the elements defined as Character.
Number

Among other uses, you can format numeric values for decimal precision, thousands separators, and currencies.
The following table describes the syntax of a Numeric Pattern string. In this pattern, all ASCII letters are reserved as pattern letters.
| Symbol |
Meaning |
| 0 |
A single digit (zero will display) |
| # |
A single digit (zero will not display) |
| . |
Decimal point |
| , |
Comma |
| - |
Minus sign |
| E |
Used in Scientific Notation. |
| % |
Display as a percent (divides by 100) |
| ' |
Escape character |
$
(Or other currency symbol) |
May need to use Unicode value (e.g. "\u00A4") for some characters. |
Examples
| Input |
Format Pattern |
Output |
| 123456.789 |
###,###.### |
123,456.789 |
| 123456.789 |
###.## |
123456.79 |
| 123.78 |
000000.000 |
000123.780 |
| 12345.67 |
$###,###.### |
$12,345.67 |
In addition to formatting patterns, there are two additional settings for handling numeric data. These situations are most commonly found with legacy systems such as AS/400.
| Field |
Description |
| Signed |
Check if data uses "signed values". Some legacy systems, particularly IBM mainframes using COBOL, denote positive/negative numbers with a special character that replaces the last digit. For example:
Note: This should not be checked for values that simply have a +/- symbol. |
| Implied Decimal |
Number of digits to regard as decimal values. Often in fixed-length files, numeric values don't have decimal points so the decimal precision can only be determined by an assumed number of decimal digits. For example, a ten character price field with Implied Decimal = 2 would be translated like this:
0000012399 --> 123.99 |
Date/Time

Formatting dates and times is required in almost every integration so understanding date format syntax is important.
The following table describes the syntax of a Time Pattern string. In this pattern, all ASCII letters are reserved as pattern letters.
| Symbol |
Meaning |
Presentation |
Example |
| G |
era designator |
(Text) |
AD or BC |
| y |
Year |
(Number) |
1996 |
| M |
month in year |
(Text & Number) |
July & 07 |
| d |
Day in month |
(Number) |
10 |
| h |
hour in am/pm |
(1~12) (Number) |
12 |
| H |
hour in day (0~23) |
(Number) |
0 |
| m |
minute in hour |
(Number) |
30 |
| s |
second in minute |
(Number) |
55 |
| S |
Millisecond |
(Number) |
978 |
| E |
day in week |
(Text) |
Tuesday |
| D |
day in year |
(Number) |
189 |
| F |
day of week in month |
(Number) |
2 (2nd Wed in July) |
| w |
week in year |
(Number) |
27 |
| W |
week in month |
(Number) |
2 |
| a |
am/pm marker |
(Text) |
PM |
| k |
hour in day (1~24) |
(Number) |
24 |
| K |
hour in am/pm (0~11) |
(Number) |
0 |
| z |
time zone |
(Text) |
Pacific Standard Time |
| Z |
timezone offset |
|
-0500 |
| ZZ |
timezone offset
(common web services format) |
|
-05:00 |
| 'Z' |
Convert value to UTC time
(special behavior, see examples below) |
|
<datetime value>Z |
| ' |
escape for text |
(Delimiter) |
|
| '' |
single quote |
(Literal) |
' |
Format Examples
| Format Pattern |
Value |
| yyyy-MM-dd'T'HH:mm:ssZ |
2007-10-29T14:30:22-0500 |
| yyyy-MM-dd'T'HH:mm:ss.S |
2007-10-29T14:30:22.586 |
| yyyy.MM.dd G 'at' HH:mm:ss z |
1996.07.10 AD at 15:08:56 PDT |
| EEE, MMM d, ''yy |
Wed, July 10, '96 |
| h:mm a |
12:08 PM |
| hh 'o''clock' a, zzzz |
12 o'clock PM, Pacific Daylight Time |
| K:mm a, z |
0:00 PM, PST |
| yyyyy.MMMMM.dd GGG hh:mm aaa |
01996.July.10 AD 12:08 PM |
Understanding Timezone Offsets
Data Maps
It is important to understand that when the mapping engine parses a value configured as Date/Time, it converts it to a special internal date format that looks like this: yyyyMMdd HHmmss.SSS. Notice the internal format does not contain a timezone offset. The implied timezone is that of the server on which the Atom, Molecule, or Cloud is running. If the source value and date mask does not contain an offset, the value will be processed assuming the Atom server's timezone. However, if the source value and date mask does contain an offset, it will automatically adjust the time value (see table below) for the Atom's timezone.
One special example that is fairly common is converting from some timezone to UTC time (0 hour offset). If the source value contains offset information and the source Profile element's input mask is configured with the appropriate date mask, the mapping engine can perform this transformation automatically.
The following table demonstrates how date values are converted from source to destination given slightly different date masks. In this example the Atom is running on a server configured as Eastern Time.
| Source |
Destination |
Comments |
yyyy-MM-dd'T'HH:mm:ss.SSS
2010-04-27T20:30:14.000 |
yyyy-MM-dd'T'HH:mm:ss.SSS
2010-04-27T20:30:14.000 |
No offset specified, no adjustment |
yyyy-MM-dd'T'HH:mm:ss.SSSZZ
2010-04-27T20:30:14.000-07:00 |
yyyy-MM-dd'T'HH:mm:ss.SSSZ
2010-04-27T23:30:14.000-0400 |
Pacific to Atom time (Eastern), value adjusted |
yyyy-MM-dd'T'HH:mm:ss.SSSZZ
2010-04-27T20:30:14.000-07:00 |
yyyy-MM-dd'T'HH:mm:ss.000ZZ
2010-04-27T23:30:14.000-04:00 |
Pacific to Atom time (Eastern), valued adjusted, common web services format |
yyyy-MM-dd'T'HH:mm:ss.SSSZZ
2010-04-27T20:30:14.000-07:00 |
yyyy-MM-dd'T'HH:mm:ss.SSS'Z'
2010-04-28T03:30:14.000Z |
Pacific to UTC, value adjusted |