Why has the non-SSC Ledger import been withdrawn from SunSystems 6 Datalink 30.002.0004 onwards?
Posted by Samer Ajlawi, Last modified by Kaize, Ahamed on 06 August 2019 03:46 PM
Why has the non-SSC Ledger import been withdrawn from SunSystems 6 Datalink 30.002.0004 onwards?
The core reason that R&D had to remove the Non SSC ledger Import data send was due to the technology that it was built on. The Ledger Import data send contains a DLL library which was built using Visual Basic 6 and could not be upgraded to .Net due to compatibility issues with Q&A 10. Without having the ability to update this DLL it caused us three key issues:
1. The Ledger Import payload was going through an unsecure method where it would do a direct SQL insert to the SunSystems Database and not following the rest of the Data Send protocols which use SSC. 
2. The DLL was tied to a specific version of SunSystems and any changes made in the SunSystems Ledger would result in a new DataLink release. 
3. The DLL showed up in our vulnerability scans when deployed in the Cloud, where it carried out direct SQL to the Database. 

It results in the following:

• All existing Data Sends using Ledger Import will need to be rebuilt using the new Layout Identifiers and appropriate mappings.
• Excel Macros should remain close to what they were before, as you are calling an internal definition name. 
• Failed Data Sends are prevented from going to SunSystems by displaying the errors in the comment cell. If the values are incorrect then yes additional work needs to be done but that would be the same regardless of the Data Send option.
• Adding this extra layer of security now brings Ledger Import Data Send in line with the rest of the SunSystems Data Sends. The fact that LI was not using SSC this was seen as a security risk. 
• In terms of applying an additional layer of authentication to SSC, this is now 
• For customers who use SunSystems and Q&A Infor provide a specific SKU covering internal use of SSC.
(0 vote(s))
Not helpful