3 Replies Latest reply on Jan 3, 2013 11:31 AM by EvanGoldstein

    Looking for input or best practices

    PaulWebb

      Hi All,

       

      I am a new developer and I have been working on a solution for my company that will support ~300+ users. My company has a tech support group that works trouble tickets. My solution connects to a DB (or will) that feeds me information about each trouble ticket (ie. ticket #, date create/close, severity, title, and so on). My users will review the tickets and use the info for reporting purposes. There is a lot of data that is incorrect in each ticket and there is a need to correct that data. The DB that my system pulls from is connected to 4 or more other DB's for its info and it is updated at various times and the info is over written each time even if there is no change in the data. My hope is to have a connection to the main DB so that my FM solution always has the most current data visible to the users.

       

      My delima...

      There are various firelds that my users will need to correct such as business impact, resolution summary, and so on. I will not have write access to the original fields coming from the DB because when the system updates it would be overwritten. How can I have a live view into the DB as well as maintain the fields my users have access to change? I want to make sure I end up with one single source of truth. Even though I will not have write access to the fields in the DB I'm connected to I can probably have new fields created in that DB for changes if it helps.

        • 1. Re: Looking for input or best practices
          EvanGoldstein

          Hi Paul,

           

          If the db you are trying to connect to is SQL, MYSQL or Oracle, you can use FM's ESS feature to add the table or a view to your solution. This way you can see the real time data. To retain the corrected fields, you just need to place them in the same (or ideally a related table) in your FM solution. You just need a key to keep each record related between the tracking system table and your FM table.

           

          HTH

          Evan

          • 2. Re: Looking for input or best practices
            PaulWebb

            Thanks Evan

             

            I don't think connecting and showing the Oracle DB fields will be a problem. I'm having a hard time wrapping my head around how to scrub data and keep it in a seperate field. It needs to be seemless to the user. So if they are editing a title field just to add "Proactive" to the beginning of the title I want them to be able to click, add it, an move on. Everytime I think of a workaround I end up with a road block as to why it won't work.

            • 3. Re: Looking for input or best practices
              EvanGoldstein

              Do your users need to make the change such as adding "proactive" again, if the data from the Oracle system changed? If so, you can set up a table that retains the data from Oracle at a point in time, and compare it to the current data. If it is different, alert the user, or put it on their "to do" list, so it can be addressed. Then update your table with the latest data, to compare to the next time the Oracle system updates. If the data does not change, then leave it as is.