SEAL scheduled

[PiotrJakubczyk]

Since Web Reports are not supported now I wonder if someone used SEAL to export import data to/from EBO. 

As I understand there is no way to schedule SEAL script to traverse EBO and generate report that can be exported to PostgreSQL or MS SQL ? 

Support email for SEAL is still  support.seal or it was changed? 

[Benji]

The SDK support reading data (IAdvanced.GetPropertyValueRecords Method) starting from EBO 7, and the function to import data from an XML file (ITrendLog.ImportLogRecords Method) has been there a while. In other words, that means you should be able to create a script to do something in that area.

That said, I would personally handle data here in a more streamlined approach where you simply use external log storage... but maybe you can elaborate a bit on the reason behind wanting to export and import?

Regarding support, since the new setup the official support for SEAL goes through the country support, and is escalated to us. For countries outside the Nordics, support is handled on the Community (as here).

[PiotrJakubczyk]

Hi @Benji 

I am looking for a more responsible, sustainable and flexible alternative to WebReports. The current state indicates that the transition from WebReports to whatever the reporting is called now was done without considering existing solutions. Currently, in many facilities, there is a meter structure created using the "Energy" folder and "energy.meter" objects that contain the measurement structure of the objects. The current "meter object" solution has integrated logs. The migration from WebReports to MeterObjects is not automated in any way, and the reporting is very limited. I do not expect MeterObject to be as powerful as WebReports, but what is currently available cannot generate a report with current readings, including the date and time of the last measurement. If MeterObject used TrendLog, I might have some trust in it, but MeterObject seems to have everything integrated within itself and only uses a data point, and it is licensed. Additionally, MeterObject does not include information such as "Meter reference Number" and "Meter Serial Number." I wonder in which country/legal system meters do not need to have a serial number in the system where they are registered... because in mine, they must... and also information about location, type of registered medium, etc. Currently, all this data is best placed in the meter's name. Placing this data in the meter's name is readable by humans, but writing a function that converts this data into a report is not easy, which prevents automatic filtering and searching. Additionally, MeterObject does not migrate existing meters from WebReports to MeterObject. I have great uncertainty about how all this will come together as a whole.

While buildings are a small problem because they might migrate a year/5 years later, industrial facilities that are constantly transitioning from Vista and growing need continuous access to reporting and the latest versions to use current controllers (in EBO3 you won't use AS-P, AS-B secure boot and just wait for the information about the withdrawal of AS-P, AS-B non-secure boot). Therefore, I am looking for alternative solutions that will be harder to remove by the product line than some "MeterObject" that is here today and might be gone tomorrow. Currently, the migration is manual, so it does not matter whether I put a lot of work into migrating to "MeterObject" or something else

additional discussions: 

https://community.se.com/t5/EcoStruxure-Building-Operation/Meter-Trend-Log-2/m-p/505374#M96340

https://community.se.com/t5/EcoStruxure-Building-Operation/Migration-from-WebReports-to-Enhanced-Rep...

[Benji]

Thanks for the elaborate response. I'll try to comment in sections.

Just for reference, you're certainly not alone in the journey from A to B, and I think it could be really beneficial to get with you regional System Architect as well as with LoB to raise your point. There's room for improvement, but I'm also sure there will come improvements.

As another comment, you're welcome to try out the attached. It's something we built to migrate to transfer data to a third party, but it seems it's on the way or path. Maybe we could make something generic, so basically migrate the "Energy" structure to Meter objects... the problem obviously being that you still have to recreate your reports, and you would have to store serial number in a variable.

But ultimately I think it's more about defining the "best replacement structure" or "migration path"... more than how to automate it - that can always be done one way or the other.

---

@PiotrJakubczyk wrote:

Hi @Benji 

I am looking for a more responsible, sustainable and flexible alternative to WebReports. The current state indicates that the transition from WebReports to whatever the reporting is called now was done without considering existing solutions.

---

I'm pretty sure a considerable amount of work did go into considering existing solutions. Main issue with WebReports (while being very powerful, agreed) is that we had tons of issues with it, due to the complexity and due to the majority of people not really being able to manage it. That said, there's absolutely no reason why you today should not use External Log Storage (with either PostgreSQL or MS SQL), and continue to use  Microsoft Reporting Services to generate your reports. That can certainly be done. The Energy objects are still available in EBO, so you can still work with that.

---

Currently, in many facilities, there is a meter structure created using the "Energy" folder and "energy.meter" objects that contain the measurement structure of the objects. The current "meter object" solution has integrated logs. The migration from WebReports to MeterObjects is not automated in any way, and the reporting is very limited.

---

Migration of data at least can be semi-automated using the Data Migration Assistant. But you're right, that's "just" for logs.

---

I do not expect MeterObject to be as powerful as WebReports, but what is currently available cannot generate a report with current readings, including the date and time of the last measurement. If MeterObject used TrendLog,

---

Not sure I understand the comment. 

---

I might have some trust in it, but MeterObject seems to have everything integrated within itself and only uses a data point, and it is licensed.

---

That it's licensed I guess will be a non-factor with EBO 7. But yes, it's licensed. The new meter objects does have a trend log "underneath", and they will certainly be expanded.

---

Additionally, MeterObject does not include information such as "Meter reference Number" and "Meter Serial Number." I wonder in which country/legal system meters do not need to have a serial number in the system where they are registered... because in mine, they must... and also information about location, type of registered medium, etc. Currently, all this data is best placed in the meter's name. Placing this data in the meter's name is readable by humans, but writing a function that converts this data into a report is not easy, which prevents automatic filtering and searching.

---

Serial number has been an articulated request, so I'm certain we'll get that.

---

Additionally, MeterObject does not migrate existing meters from WebReports to MeterObject. I have great uncertainty about how all this will come together as a whole.

While buildings are a small problem because they might migrate a year/5 years later, industrial facilities that are constantly transitioning from Vista and growing need continuous access to reporting and the latest versions to use current controllers (in EBO3 you won't use AS-P, AS-B secure boot and just wait for the information about the withdrawal of AS-P, AS-B non-secure boot). Therefore, I am looking for alternative solutions that will be harder to remove by the product line than some "MeterObject" that is here today and might be gone tomorrow.

---

The new meter objects here to stay - I think you can be pretty certain on that 🙂

---

Currently, the migration is manual, so it does not matter whether I put a lot of work into migrating to "MeterObject" or something else

additional discussions: 

https://community.se.com/t5/EcoStruxure-Building-Operation/Meter-Trend-Log-2/m-p/505374#M96340

https://community.se.com/t5/EcoStruxure-Building-Operation/Migration-from-WebReports-to-Enhanced-Rep...

---