This heading describes the various stages of creating an exchange standard when setting up an interface between CARL Source and another application.
1. Build the integration object
If the integration object you need does not exist as standard, you can easily create it from the corresponding dictionary object.
Choose the finest object in relation to your need.
For example, to import item locations, choose ITEMLOCATION rather than LOCATION or ITEM.
CARL Source initializes the list of attributes of the object. At this stage, you can keep all the attributes or delete the ones which will not be useful to you.
Warning: if the interface needs to be capable of creating records, all the object's required attributes must be included in the integration object.
2. Creating the exchange standard
Create a standard and then a standard version. Check it as "Active."
In the standard version, choose to create the records by "Integration object search"
, and select the created integration object.
CARL Source initializes the record line and the list of attributes:
Update identifier
If the data is likely to be updated if it already exists in the database, the first field or fields must be capable of identifying the element to be updated.
It is built in this way <Object name>::<identifier attribute> .
The functional identifier may consist of several indirect attributes.
In this case, a field must be created for each component using the format <Object name>::<identifier attribute> or <Object name>::code_ref if the identifier is an object recognized by its code.
Examples:
The field alias budgAcc::code refers to the budget code, which determines the budget in a unique way.
The two fields itemWarehouse::item_coderef and itemWarehouse::warehouse_coderef are necessary to designate an item-warehouse link in a unique way.
The two fields PRLine::PR_coderef and PRLine::lineNumber are required to designate a PRL.
Attributes in the event of creation
Next, if the data is likely to be created (i.e., if the interface does not only do updates), the list of fields must include the required fields of the object.
These fields were created when the record was created by selecting the integration object.
They have the format: <Object name in lower case>_<attribute with its upper-case letters>.
If the attribute is an object, the attribute designating the object must be specified by adding ::<identifier attribute>.
This is generally the code that will be indicated in the file ::code.
Example:
budgacc_code, budgacc_supervisor::code, itemwarehouse_warehouse::code, poline_lineNumber.
Example for a composite item identifier attribute:
deliveryline_PRLine::PR_coderef and deliveryline_PRLine::lineNumber
Numbering, format, transformations
Delete fields that you do not need.
Be careful to number the fields from 1 to n in the same order as in the file.
If the file has a separator, indicate it in the header of the standard version.
If, however, the column positions are fixed, fill in the size for each field.
The size of the record prefix is 20 characters as default.
To apply formats or changes of fields upon import or export, access the transformations form for each record in question.
3. Create interfaces
Indicate the applicable version in the standard.
Create the output interface. Even if it is not useful in the long run, it makes it possible to check the file format corresponding to the standard during fine tuning:
Then execute the output interface and consult the resulting file. Make sure its format is correct. Adjust the standard, if necessary.
Lastly, create the input interface by copying the output interface.
Change the exported file header to indicate the code of the input interface: exchangeInterface;<interface code>;
Run the input interface. Any errors will be indicated in the executions history.