Skip to main content
When migrating assets and users from one server instance to another there seems to be an issue. This may of course be an issue of my comprehension - failure to read correct docs etc.



Export of assets [or users] to CSV works fine; SysAid produces a valid CSV file.



However when one seeks to Import the same file into another instance of SysAid the product does not have an "option" which automatically recognises its own CSV files.



Worse, when one comes to select the various possible headings under which the existing fields of the CSV should be imported, the names in the dropdown selector don't match up in any meaningful fashion with the names/labels of fields as normally displayed in SysAid pages - so one has great difficulty determining which labels should be selected.



These mappings of source data to target should be entirely automatic unless the sysadmin elects to make manual changes - which should be a discrete and separate import option..



In other words on import SysAid should be able to recognise its own output data; it should then be able to import that data without modification or user intervention, and the results should display exactly as they did in the source system prior to export.
Wait... is this for selected user/assets or the entire thing ?



If it's the entire thing...

Arent' you supposed to do that with a backup-here-restore-there thingy ?
I wanted to test exporting assets /and/ exporting users, each as a discrete action.



So when I saved the asset.csv file from one SA install I expected to be able to import it unattended into another but different and clean install of SysAid on a different machine. Which I thought was a relatively reasonable expectation.



What I actually found was that SA expects me to go through the process of mapping all the source and target fields to each other; this was all the more irritating because the CSV file had a header row in place - unfortunately these are headers which do not map to the field names/descriptions in SAs import fields. Telling SA to ignore the header row without mapping the fields created a nice mess, whilst telling it not to ignore the header row created a different nice mess.



The general conclusion was that it's better and less chaotic to map source and target fields. However take a look at this asset.csv header row



"Name","Group","Location","Description","IP Address","Type","Manufacturer","Serial","Purchase Date"



1] those headers only represent the primary display of the Asset List - if I want to export an asset list then I want ALL of the attribute data for each asset as a single operation; and if I don't get to export all of it in one operation then I want control over the elements that do get exported.



2] There appears to be no automated mechanism for importing asset [or user] data from a csv created by SA itself. That's a gap in the feature set and coding, quite apart from the fact that the csv header rows don't seem to map correctly to ANY of the descriptions in the file import fields.



3] There doesn't appear to be any way to export ALL of the data for one, some or all of the assets on an SA system. That strikes me as an oversight.



4] There appears to be an additional and hidden problem with import; if the assets in question are located within a group [i.e. the group field attribute of the csv has data in it] and one imports that CSV file AND that group does not already exist on the SysAid server then my tests seem to indicate that we generate chaos. Ditto for Locations and Manufacturers if these elements have not previously been recreated/configured prior to import.



I'll readily agree that I'm a newbie with SA and could easily be doing things incorrectly, but it doesn't feel that way to me right now ....



NB: please don't feel I'm having a go at you, or at Illient; I'm mostly just puzzled by these apparent oversights,



LATE EDIT:



OK, I've just started to explore the Analyzer functions, and first impressions are I spoke a little quickly: it seems to cover some of the issues I was talking about. I'll let this message stand for now whilst I continue exploring.
Hello RobertN,

Welcome to the SysAid community.



I can understand that you are having difficulties using the import asset from CSV option, as it require understanding as how the import works and how to configure it.



The import option is completely done by hand (choosing the amount of columns to import and to which field) since it need to support a wide range of CSV files, and not just files that has been exported from SysAid.



Below you can find the instructions that we provide on how to import assets into SysAid by using the CSV file, I hope you will find it useful in your implementation process:



1. In order to import assets from a CSV, you will need to have a properly created CSV file that uses a “,” (comma) as the field separator. After choosing the file using the “Browse” button, select the fields in the correct order that represent the information in the CSV file (e.g. Asset name, Manufacturer, Model, Serial number, ...). When you are done, click on “Submit”.

2. Do not try to import the “Location” field into SysAid. “Location” is a special list type field that accepts index integer keys that have been predefined in SysAid with the appropriate caption names. It is therefore impossible to import text into this field.

3. If you have clicked on “Submit” and then receive an error, note the line/column number stated in the error, and then open your CSV file and locate that position. Try to determine the reason for this error, or ask the Ilient Support staff regarding this issue.

4. The format column is only used for the Date field. In the Date field, you need to enter the syntax in which your date is built. For example (d=day, M=month, y=year):

a) 01/02/06 - dd/MM/yy or MM/dd/yy

b) 13/06/2006 – dd/MM/yyyy

c) 1/6/06 - d/M/yy or M/d/yy (will not include preceding zeros)

5. If you change the number of fields without selecting a file from which to import assets and then click “Submit”, the page will be refreshed with the additional fields.



Best regards.

Haim
Thanks for the welcome Haim



And a further thank you for confirming to me that SysAid exports asset csv files which are not written in formats that SysAid can import automatically.



Note that I wasn't specifically looking for a way to do imports manually; I was testing all of the various mechanisms for portability of the data across systems for the purposes of business continuity and systems and disaster management.



To that end I was



a] asking why SysAid is not capable of importing its own files automatically. The time one MOST needs to import files is during a disaster recovery when one is under pressure - and when mistakes are most likely to happen. Automating the process reliably would make a great deal of sense.



b] suggesting that the mismatch between export and import field names and formats is a fairly silly flaw in the design and coding of SysAid.



As an example of how that flaw in the coding is blocking the user let me offer this: with date formats, most software implementations make the reasoned assumption that the date content in any structured data store is recorded in UTC whilst the display format will match the current region/location setting for the host system, thus ensuring that there is no requirement for user intervention during data import.



If it is necessary for the user to vary the display format from the system defaults then the user has [or should have] the option to reset globally or on a per page basis after import. But to cause the entire import process not merely to fail - but to fail chaotically with corrupted data - because of lack of thought during the software design phase is NOT good practice. Why does import fail? Because the SysAid CSV export option is NOT recording date content/format at all despite the csv header row suggesting that the field content exists.



I've tested this by exporting several different asset csv files from more than one trial SysAid system and in each case the date field is not properly recorded: the last field recorded in any given row is the serial. The fact that the content structure doesn't match the header structure means that it is not in the least bit surprising that import fails.



To put this all in a simpler language; the data handling for export/import appears to be too complex and insufficiently reliable for continuity and disaster recovery purposes, which is actually the moment one needs SysAid most urgently.
Robert,



I'm very sorry for this misunderstanding, since SysAid CAN import the csv files it has exported



Please send us an email to helpdesk@sysaid.com with a screenshot of fields you are placing in the import asset page, a copy of the CSV file, and the error you are receiving.



Best regards.

Haim
Haim



I'll send you some email shortly.



However your message does imply that SysAid can indeed not import files automatically, and that to me is the single most important problem.



Haim


I'm very sorry for this misunderstanding, since SysAid CAN import the csv files it has exported



Please send us an email to helpdesk@sysaid.com with a screenshot of fields you are placing in the import asset page, a copy of the CSV file, and the error you are receiving.


RobertN
Haim



I'll send you some email shortly.



However your message does imply that SysAid can indeed not import files automatically, and that to me is the single most important problem.



Haim


I'm very sorry for this misunderstanding, since SysAid CAN import the csv files it has exported



Please send us an email to helpdesk@sysaid.com with a screenshot of fields you are placing in the import asset page, a copy of the CSV file, and the error you are receiving.





What I was trying to say is that SysAid cannot import the files it export AUTOMATICALLY, but you can configure it (just like the import asset page) with the fields you want to import to it, and then import all the assets.



Best regards,

Haim
Ma come si fa ad esportare mantenendo all'interno del CSV la correlazione con gli allegati?

Reply