Migration from the SQL version of the BFUS Integration¶
An upgrade mostly consists of reviewing the customers current Lime structure compared to the BFUS addons standard setup and the specification provided by the customer. Even though all configuration is done with the specification in mind, the mapping and specification needs to be carefully compared to the current Lime structure. Assumptions is the mother of all f ups, don't assume that the specification is foolproof.
Review field specification¶
Go through the BFUS field specification and adjust the “customer choice”-column and “Custom field name” according to the customers current setup. A common occurance is that the specification specify the use of the standardized fields, but in reality the customer already have another field for that data. With a different field type, wrong character length, different name or such.
Example of this could be a deviation in limetype, fieldname and field type, see below.
Current Lime structure:
| table name | field name | field type | length |
|---|---|---|---|
| customer | customerno | int | n/a |
Standard addon structure:
| table name | field name | field type | length |
|---|---|---|---|
| company | customercode | text | 32 |
Lime structure¶
After reviewing the specification and the Lime structure as well as identifying possible problems, either one of those need to change. This is to make certain that the mapping will be correct.
A thumb of rule is that if a field already exists under a different name than the standardized fields, the old field should be used to make certain that other integrations and customizations continue to work as intended.
On the other hand if the field has the same name but different field type, mostly concerning ID-fields, the field ought to be changed to text. This is done through a migration explained below.
Replace old integer key fields¶
Note if they have the old integer key fields, if so these needs to be replaced when doing the installation, but not before because the new field will not work with the old solution (without modifications).
At installation the old integer key fields should be renamed with affix _old. Make sure that the new ones are included in the LIP-package that will be built. Note: When the lip package has been installed the data needs to be migrate from the old fields to the new ones.
- Rename old int field, both swedish and database, by adding "_old" as an affix. E.g "customerno_old"
- Add a new field per standard addon structure for this field. E.g db name: "customerno", length: 32 and type: text
- Through SQL Server Management Studio (SSMS) run the following query:
BEGIN TRANSACTION
UPDATE c
SET customerno = customerno_old
FROM customer c
WHERE customerno_old IS NOT NULL
To review the change run the following query:
SELECT idcustomer, customerno, customerno_old
FROM customer
If the change is correct either run commit (deploy change) or rollback (revert change)
| table name | field name |
|---|---|
| company | customerid |
| contract | contractid |
| flexservice | flexserviceid |
| flexserviceplace | flexserviceplaceid |
| productcomponent | productid |
| service | serviceid |
| service | servicedistrictcoolingid |
| service | servicedistrictheatingid |
| service | serviceelectricid |
| service | servicebroadbandid |
| service | servicereadinginfoid |
| serviceplace | useplaceid |
| site | siteid |
Customizations¶
See if there are any solution specific customizations in their sql procedures. If you are not familiar with the procedures one way of doing this could be to compare the procedures at the customer with the ones on F (F:\Common\Industry Experts\Utility\Integrations\BFUS\Procedures).
If they have any customizations these need to be translated into python customizations or if possible as adjustments in the mapping (for example secondary keys).