Background
A lot of legacy inventory vendor platform was built on a generalized system, which closely resembles ServiceNow (SN) in architectural flexibility and extensibility but uses outdated technology and principles. At its core, the legacy inventory vendor organized data across major tables that defines objects, types, parameters, attributes, and references in one way or another (there are maybe some variations across vendors, but on average it will be the same). This design offered robust data generalization and adaptability, allowing various business needs to be addressed without frequent schema changes. However, the downside of such generalization was the impact on performance, especially as data volume and query complexity increased. Large-scale extractions and integrations would often strain the database, resulting in significant slowdowns
resource contention.
Performance Optimization: Replicated Subset Database
To mitigate these performance concerns, the legacy inventory vendor implemented a workaround, let’s call it Replicated Subset Database (RSD) mechanism. RSD creates a clone of the production database, enabling targeted extraction and import activities to be carried out without interfering with the main system’s operations. This replication is not static; table configurations can be tailored during setup to ensure only the required datasets—such as specific objects, types, attributes, or references—are captured. Importantly, RSD supports bidirectional data flows: not only can data be efficiently extracted for analysis or integration, but changes can also be pushed back into the main legacy inventory vendor environment if needed. This architecture greatly improves operational efficiency and system reliability.
Data Extraction & Synchronization Options
For integrating SN and the legacy inventory vendor (for example SN TNI and legacy inventory vendor resource inventory), three primary technical methods are available, each with distinct advantages and limitations:
API Integration (Custom J2E/SOAP)
- If the legacy inventory vendor does not provide an open API out of the box, integrations require custom adapters built using J2E or SOAP.
- Developing these APIs involves formal change requests and approval cycles, which can be time-consuming and costly. There is also no guarantee that the legacy inventory vendor will authorize the necessary access or modifications.
- Any custom solution must be sufficiently generalized to support all extraction requirements over the duration of the project. Maintenance and scalability are also considerations, as ongoing business needs may introduce new use cases.
Database Copy & ETL Adapters (Recommended for full migration)
- Full DB copy to be created.
- With the data structured in five well-documented tables, architects or developers familiar with the legacy inventory vendor can easily create ETL (Extract, Transform, Load) adapters based on a database copy.
- This method allows direct access to underlying data, bypassing API constraints. However, it will significantly affect performance of legacy inventory so this method can be used only for the full migration, as during the data extraction data would not be operational.
Replicated Subset Database (RSD) (Recommended for co-existing)
- RSD creation can be initiated by CSP (customer), your team, or the legacy inventory vendor. The mechanism is established within the legacy inventory vendor and allows for precise table configuration at the data configuration stage.
- This approach is highly scalable and supports efficient extraction and bidirectional synchronization. It is particularly suited for complex scenarios such as synchronizing cables, parameters, or specialized attributes between TNI and the legacy inventory vendor.
- RSD minimizes production impact and can be reused for future integration or migration needs. It also ensures high performance even as data volumes grow.
- Adapters and parsing logic can be specifically tailored during setup, enabling rapid deployment and robust data integrity.
Implementation Steps
- Engage with stakeholders to plan RSD setup and allocate necessary resources. Example below for the use when data must co-exist while some will be migrated.
- Review technical documentation for legacy inventory vendor table structures, RSD configuration, and data management procedures.
- Define the scope of data domains and configure tables accordingly for replication.
- Develop and test ETL logic and adapters for seamless extraction and synchronization.
- Validate bidirectional flows in a controlled test environment to ensure no impact on production performance.
Conclusion
For stable, high-performance data integration between SN and the legacy inventory vendor, the RSD mechanism is the optimal solution for migration procedure and full DB replica if it’s possible for full one-time migration. RSD offers precise control, scalability, and minimal operational risk compared to alternative methods. Teams should leverage legacy inventory vendor documentation and collaborate closely with architecture and development stakeholders to ensure a smooth, secure, and technically sound implementation.
#TNI #Inventory
