Release Notes – WMS Recovery and SP13 Upgrade
Client Side Component Installation
This part of document will explain installation procedure for client side components for Vin & Sprit Fidaware, ESCON, Finance, Produktguiden and EDIMAN integrations. Assuming that the current client side environment at V&S remains the same, the details regarding system are not explained.
Note – Naming conventions
Naming convention followed for Broker ofas is as follows
For new deliveries, upgrades
VNS<Interface name OR location>_Date<yyyymmdd>_<port>.ofa
For cases solved
VNS<case number>_Date<yyyymmdd>_<port>.ofa
<port> indicates on which Broker port the ofa should be imported.
This convention will be followed for all the deliveries now on.
Delivery Contents
1. COM DLLs
2. Ofa – for changed Broker side components
3. Sample configuration files for reference
4. SQL Scripts for CAPS tables, GUID table, update trigger for data sent date
1. WMS (FIDAWARE, ESCON)
The delivery contains the client side components tested for SP13 upgrade of BaanERP 5.0c and the components redesigned for recovery process.
Installation Procedure
1. Copy the COM dlls from the delivery into a folder on Broker server machine (Suggestion, create a VNSCOMDLLs folder to copy the COM Dlls). List of COM DLLs is as follows
a. B50cVNSwheszPlanningDataForFW.dll
b. B50cVNSwhinhInboundOrders.dll
c. B50cVNSwhinhListOutboundOrders.dll
d. B50cVNSwhinhOutboundOrdersforESCON.dll
e. B50cVNSwhinhReceipts.dll
f. B50cVNSwhinhUpdateOutboundAdvice.dll
g. B50cVNSwhwmdItems.dll
2. Un-register the old COM DLLs (delivered for UpdateOutboundAdvice)
3. Register the new COM dlls
4. Restart the Broker server
5. Import ofa VNSWMS_20031010_7250.ofa on port 7250
6. Import ofa VNSWMS_20031010_7251.ofa on port 7251
7. Run the SQL scripts from folder SQLScripts on VNS_DATABASE, there are two scripts delivered –
i. CAPSDB.sql – for creating CAPS tables on the SQL server. The CAPS interface will use the MS SQL server as intermediate database for integration
ii. trUpdateData_received.sql – trigger for changing the data when data sent from Fidaware to Baan is changed. This is provided as a workaround as date updated from Broker was not correct.
iii. Upload_GUID_table.sql – Upload_GUID_table is modified to add one more field for CAPS id, the old table will be dropped and new one will be created with this script
8. Check the configuration files against the files provided in the sample configuration files in the delivery. Points to be noted
a. DSN for CAPS is pointing to MS SQL instead of Oracle
b. TimeOut tags are present for all the interfaces as in the sample configuration files – initial value for timeout is set to 60000ms (10min), on timeout this will be updated automatically by Broker to maximum (180000) 30 minutes.
9. Periodic processes for upload data for all streams and download data for all streams are updated with appropriate calls and are renamed to ppUploadAllStreamsNew, ppDownloadAllStreamsNew. Instead of old periodic processes these new ones should be used (can also be renamed to same name as earlier)
10. The tasks called from Launch application are also updated, Launch can be used with the new components
Note – new version of Launch will be delivered soon but the present version is also
With this installation procedure gets over
Post installation
After the installation is over run the following script from OW Designer
For Fidaware – “VNSWMSGlobalObjectsConfigurationParametersgetConfigParameters”
(On both ports 7250, 7251)
For ESCON
“VNSESCONGlobalObjectsConfigurationParametersgetConfigParameters”
Note – getConfigParameters script mentioned above has to be run every time the configuration file is changed manually. Configuration file can be changed using Launch application but until the next version of Launch application is released, getConfigParameters script should also be run for changes in configuration parameters using Launch. The new configurations will not be applicable otherwise.
2. Finance (Resax, Lon, EPOS, TWIN) and Produktguiden
Delivery for finance interfaces contains client side components tested for SP13 upgrade of BaanERP server side components and changes for performance improvement for EPOS and TWIN. Delivery for Produktguiden contains changes on performance improvement.
Installation Procedure
- Copy the COM dlls from the delivery into a folder on Broker server machine (Suggestion, create a VNSCOMDLLs folder to copy the COM Dlls). List of COM DLLs is as follows
-
- B50cVNStfgldBankTrans.dll
- B50cVNStfgldTransactionsTwin.dll
- B50cVNStcibdProdukts.dll
- Un-register the old COM DLLs (delivered for UpdateOutboundAdvice)
- Register the new COM dlls
- Restart the Broker server
- Import ofa VNSSweden_20031010_7252.ofa on port 7252, contains Broker components for Resax, Lon, Twin and Produktguiden
- Import ofa VNSDenmark_20031010_7253.ofa on port 7253, contains Broker components for ESCON, Finance (EPOS), EDIMAN
- Check the configuration files against the files provided in sample configuration files in delivery. Points to be noted
-
- DSN for Produktguiden is pointing to correct MS SQL server
- TimeOut tags are present for all the interfaces as in the sample configuration files – initial value for timeout is set to 60000ms (10min), on timeout this will be updated automatically by Broker to maximum (180000) 30 minutes.
- Note – the parameter files (not configuration files) for finance or and the EDI configuration files are not changed
- Periodic processes for upload data for all streams and download data for all streams are updated with appropriate calls and are renamed to ppUploadAllStreamsNew, ppDownloadAllStreamsNew. Instead of old periodic processes these new ones should be used (can also be renamed to same name as earlier)
- The tasks called from Launch application are also updated, Launch can be used with the new components
- For Twin create following folder in location D:DataVNSFinanceTWINInputFilesTempFiles.
Note – new version of Launch will be delivered soon but the present version is also
With this installation procedure gets over
Post installation
After the installation is over run the following script from OW Designer
For Finance on ports 7252 and 7253
“VNSFinanceGlobalObjectsConfigurationParametersgetFinanceConfigParams”
For Finance in addition to this for finance parameters also run following script on 7252 and 7253
“VNSFinanceGlobalObjectsParameterFilegetFinanceParameters”
For ESCON
“VNSESCONGlobalObjectsConfigurationParametersgetConfigParameters”
For Produktguiden
“VNSProduktGuidenGlobalObjectsConfigurationParametersgetConfigParameters”
Note – getConfigParameters script mentioned above has to be run every time the configuration file is changed manually. Configuration file can be changed using Launch application but until the next version of Launch application is released, getConfigParameters script should also be run for changes in configuration parameters using Launch. The new configurations will not be applicable otherwise.
EDIMAN
For EDIMAN integration the delivery contains client side scripts for EDIMAN tested for SP13.
WMSTransaction control, Download, BaanERP 5.0 c SP13 for V&S
This process explains of the server side process of download data from Baan to Fidaware. The different data that can be downloaded is:
· Item Data
· Inbound Orders
· Outbound Orders (both for Fidaware and ESCON)
· Planning Data
Detailed information about the download process can be found in the detailed design document 110101D001-2.2 delivered earlier
Scope
Download process
Download of data is done depending on the sent to WMS parameter.
When sent to WMS parameter is “yes” (2), the old (already sent) data is downloaded from Baan to Fidaware, and when the sent to WMS parameter is “no” (1), only the new data after last download is sent to Fidaware. The old process worked in such a manner that after download of new data, the sent to WMS flag, which is “no” for new data, was set to “yes” just when the data is downloaded from Baan. The disadvantage in this process was that if the download process fails after download of data but before the data actually reaches Fidaware, the status of the sent to WMS flag for the record will remain as “yes”. This is an incorrect stage. In the current delivery, which includes changes in the BOI DLL’s for download of different data, this process is changed. Now the data will be downloaded depending on the sent to WMS parameter, but in case of new data, the sent to WMS flag will not be changed immediately. After the whole downloaded data reaches Fidaware, an acknowledgement call is sent from OW client back to server. Within the BOI DLL an additional method is written to set the sent to WMS parameter for the records which have been successfully received. The acknowledge method will update the database with the sent to WMS flag as “yes”. The process of data download and planning methods is explained in the detailed design document.
Installation Procedure
Components to install
The whole solution is delivered in two parts: one, the PMC-solution, the other part is the OpenWorld related components. Both solutions must be implemented at the same time otherwise this solution will not give the desired result.
Pre-condition
BaanERP 5.0c SP13 should have already been installed
Modified Components
BOI DLL – Whboidll600001 – BOI DLL Items download V&S
BOI DLL – Whboidll600002 – BOI DLL Inbounds download V&S
BOI DLL – Whboidll600007 – BOI DLL Outbounds download V&S Escon
BOI DLL – Whboidll600008 – BOI DLL Outbounds download V&S Fw
BOI DLL – Whboidll600010 – BOI DLL Planning Data V&S
Transaction Control within iBaan OpenWorld Broker for V&S Download Process
This part of document will explain the transaction control of download process within iBaan OpenWorld Broker to achieve the recovery of data in case of failure with respect to the Broker components. More details about the complete process are provided in the document 110101D001-2.1.
The download process applicable for all streams reworked for WMS recovery
Process of download outbound orders within the iBaan OpenWorld Broker
Download of data from Baan to V&S Fidaware application starts with a download periodic process running within the Broker service. This process can also be initiated using Launch application.
The periodic process calls the iterator object of iBaan OpenWorld Broker for the respective process. The source and destination (in this case BaanERP and Fidaware respectively) components of iterator take care of sending the request and getting response. Response in this case is the downloaded data for outbound orders. The flow of the process is as follows
Download Process
1. Check if the iterator is already running – by checking if the timer assigned for the specific process is running (Timer 1 is used for download outbound orders)
2. If yes, then exit the operation throwing exception 1001 else continue – this is done to make sure that periodic process and manual process (using Launch) do not interfere. Only one process can be run at a time to avoid the conflicts between Broker’s shared resources
3. Read the parameters for download from the global variable, parameters are specified by user if the download process is initiated from Launch or in case of periodic process default parameters are used
4. Read the bus component for socket connection to Baan, Timeout parameters from the global variable. Global variable reads these parameters from the configuration file, hence the configuration file should be updated with all the parameters in advance, and new parameters should be read by running the getConfiguration script from Broker designer for VNSWMS
5. Initialize the BOI Manager in Initialization part of iterator. Manager object will be kept in the state object of the iterator, so that it is used globally for that iterator. Close and releaseAll the object in case of any exceptions and normally in finish of the iterator
6. In the initialize give a call the BaanERP to run the List method and download the data. The data is stored in the iterator of BOI manager
7. Within the iteration step of iterator unwrap get the data in the rowtypes and tables of Broker. Send the data to all the destination components, one record at a time
8. When the Data arrives in the Fidaware component of Broker, create the XML out of it and send the data to the MS SQL table
9. After each successful insertion of record into the MS SQL set the status of record to ‘O’, write the primary keys for the record into the temporary table
10. If there is an exception due to connection failure, then abort the execution of subsequent, send the mail to respective email id for the stream
11. When all the records are successfully sent to the intermediate tables for Fidaware/CAPS, in the finish method of iterator process the temporary table to send an acknowledgement of successful receipt to the Baan. For this another method acknowledge is called to send all the primary keys of successfully received records, with BOI an update method is run for all the records to make the sent to WMS flag as “yes”
WMSTransaction control, Upload, BaanERP 5.0 c SP13 for V&S
This process explains of the server side process of upload data into Baan. The different data that can be uploaded is:
· Inbound Orders (Receipts)
· Outbound Orders
· Planning Data
Detailed information about the upload process can be found in the detailed design document 110101D001-2.2 delivered earlier
Scope
Upload process
As an overall solution OpenWorld Broker will perform an extra task to control the data transfers between the applications more extensively. For each data transfer via temporary tables OpenWorld Broker will keep track if the data is fully received and handled. Within the above-mentioned detailed design document for all upload processes the extra control of the data transfer between the applications will be explained in detail.
Here is an addition to the detailed design document.
To improve the performance multiple streams can be defined for the upload processes. The recovery process should also support this. Therefore the port number is stored in the GUID table as well as on the broker side as in Baan. Then the recovery process can run per port.
Installation Procedure
Components to install
The whole solution is delivered in two parts: one, the PMC-solution, the other part is the OpenWorld related components. Both solutions must be implemented at the same time otherwise this solution will not give the desired result.
Pre-condition
BaanERP 5.0c SP13 should have already been installed
Post-condition
Since this solution holds a modified table it is required to create runtime data dictionary after installation and create the new table after this. At the bottom of this document you can see the new/changed components for this solution.
Modified Components
Component Type |
Component Code |
Component Description |
Table |
Tccom932 |
WMS Transaction control |
Script/Object |
Tccom932 |
DAL for tccom932 |
Script/Object |
Whboidll600003 |
BOI DLL Receipts upload V&S |
Script/Object |
Whboidll600006 |
BOI DLL Advices upload V&S |
Script/Object |
Whboidll600010 |
BOI DLL Planning Data V&S |
Script/Object |
Whinhdllc002 |
Combine Shipments DLL |
Script/Object |
Whinhdllc003 |
Receipts DLL |
Label |
Tccom932.port |
Port number |
Label |
Tccom932.idnr |
ID |
Transaction Control within iBaan OpenWorld Broker for Vin & Sprit Upload process
This part of the document will explain the transaction control of overall upload process within iBaan OpenWorld Broker. This will explain the process only with respect to the Broker components, more details about the complete process are provided in the document 110101D001-2.1.
Process of update outbound advice within the iBaan OpenWorld Broker
Upload process from V&S Fidaware application to BaanERP starts with a periodic process running within the Broker service.
The periodic process calls the iterator object of iBaan OpenWorld Broker for the respective process. The source and destination (in this case Fidaware and BaanERP respectively) components of iterator take care of sending the request and getting response. The flow of the process is as follows
Upload Process
3. Check if the iterator is already running – by checking if the timer assigned for the specific process is running (Timer 0 is used for upload outbound advice)
4. If yes, then exit the operation throwing exception 1001 else continue – this is done to make sure that periodic process and manual process (using Launch) do not interfere. Only one process can be run at a time to avoid the conflicts between Broker’s shared resources
5. Fetch the records from database (MS SQL), orders with GUID first, indicating failed orders from earlier run and then the new orders in “ascending” order. UPLOAD_GUID_TABLE is created to store GUID for each stream
6. If there is some row in GUID table but corresponding status of record in the upload_table is “p” or is not there, then there was some problem, and record was marked as processed. Delete entry for such record from GUID table
7. Fill up the result table with upload_id and data and send table to the iterator
8. Initialize the BOI Manager in Initialization part of iterator. Manager object will be kept in the state object of the iterator, so that it is used globally for that iterator. Close and release the object in case of any exceptions and normally in finish of the iterator
9. Within the iterator unwrap the XML to get the data in the rowtypes and tables of Broker. Send the data to all the destination components, one record at a time
10. When the Data arrives in the BaanERP component of Broker, sort the data in order if required (required for outbound advice)
11. Create the business objects for upload process, fill up the data and send request to Baan
12. If there is an exception due to connection failure, then abort the execution of subsequent records and leave the records unprocessed i.e. with status ‘O’. Record the error in database, send the mail to respective email id for the stream
13. Else wait for the response from Baan, if there is a timeout before the response comes back, then there is a possibility that the timeout was short for the size of record. Hence increase the timeout in the configuration file for the stream. Since there was no response back from the ERP, we do not know if the record was processed successfully hence keep status of the record as unprocessed i.e. ‘O’, but do not delete the GUID from the GUID table, so that the record will be processed again I next run in a “Recovery Mode”. The BOI will take care of the recovery
14. If there is any exception in Broker, the Broker will not delete the GUID from the GUID table, and will pick it up again for recovery
15. In case of normal responses and known errors, Broker will make the status as ‘P’ or ‘E’ in the upload_table and delete the GUID from UPLOAD_GUID_Table
Transaction Control within iBaan OpenWorld Broker for TWIN and EPOS
Broker side component structure for TWIN and EPOS has been changed to take out the iBaan OpenWorld Gateway component from the scripts and use the COM DLL instead. There is no change in the functional design of the interface
How the new components work
- In the new design the there will be no change in the invocation of the TWIN process. As earlier the file/files will be put into the D:DataVNSFinanceTWINInputFiles folder.
D:DataVNSFinanceEPOSInputFiles folder.
- The User will start the process, using Launch, or a periodic process if running will pick up these files at subsequent run.
- For TWIN, the message handler will poll the new files and will create a temporary TWIN file with the data in the TempFiles folder. This is a new folder and will have to be created in location D:DataVNSFinanceTWINInputFilesTempFiles.
This is not applicable for EPOS
- The file being processed will be moved to OldFiles folder, on error, the file will be stored in ErrorFiles folder with name TWIN/EPOS appended by timestamp.
- The message handler will call the file processing Broker script. Within the script the file contents will be parsed and business objects for TWIN/EPOS will be created using the COM DLLs mentioned in installation procedure above. Broker will give a call to BOI on BaanERP and will wait for response.
- All the errors (infrastructure / parsing / Functional) will be notified via e-mail and will be logged to database, Broker event viewer. Broker event viewer must be configured to view the logged events. Events will be logged as Transactions
- User will have to make correction to ASCII files if needed and reprocess the file. In case of timeout errors the default timeout will be increased automatically and will be saved to configuration file. A new tag (<TimeOut>) has been added to configuration file for this.
- The event logs can be viewed through Launch. Successful events will be notified via e-mail with batch numbers created and also will be logged.
How to run all solutions
Solutions can be run as before from Launch and using the periodic process as earlier
Some additional information
Exception codes for V&S Broker scripts
For WMS and common codes – exception codes start from 1001 and ahead
Code |
Description |
Reason |
1001 |
Iterator already running |
The time assigned to iterator is still running |
1002 |
Did not receive |
Timeout for adapter reached |
1003 |
BusDocFailure to get socket connection |
Socket connection to Baan may be closed |
For Finance exception codes start with 2001
Code |
Description |
Reason |
2001 |
File not balanced, debit is not equal to credit |
Error in ASCII File |
2002 |
File cannot be processed |
File is empty |
Timers
Timer Number |
Stream |
0 |
Update outbound advice |
1 |
Download outbound orders |
2 |
PlanningDataForFW Change |
3 |
PlanningDataForFW List |
4 |
Download InboundOrders |
5 |
CreateReceipts |
6 |
Items Fidaware |
7 |
Items ESCON |