New post
AllAccepted answers
Sam Duncan · Jan 2, 2019

For the Fact and Indices databases journaling is optional and depends on the business needs. It might preferable to disable journaling when cubes are relatively small and fast to build, or  cubes are scheduled to rebuild periodically.

Enable journaling on this database when cubes are relatively big and it takes too long to rebuild them. The ideal case to keep journaling on is when cubes are in a stable state and only get periodically synchronized, but not built. One way to safely build cubes is to temporarily disable journaling for the Fact database.

One thing to keep in mind is that when DeepSee synchronizes a cube, each update/insertion of a fact (along with the associated updates/insertions to the DeepSee indices) is done inside of a transaction. This means that there will be journal activity on ^DeepSee.Fact and ^DeepSee.Index when synchronizing even if those globals are mapped to a database (such as APP-FACT, in this example) that does not have journaling enabled.

When DeepSee builds a cube, updates and insertions on the fact table and indices are not done inside of a transaction. A build should cause journal activity on ^DeepSee.Fact and ^DeepSee.Index if and only if those globals are mapped to a database for which journaling is enabled.

Sam Duncan · Sep 17, 2018

There is one other mapping that might be useful to add in this architecture: The ^DeepSee.Listing global can be mapped to the APP-CACHE database, as described here. A large amount of data can be written to ^DeepSee.Listing if listings or plugins are run on cells containing many facts, and this global does not need to be journaled - listing queries will be rerun every time the listing in question is viewed.

Sam Duncan · Jul 31, 2018

Hi Karthik,

You could try creating a custom action to do something similar to this. There is documentation on custom actions here. For example, I believe you could define a KPI class with a custom action that opens a web page  with the information you want to display in a new window. You could then add a control to your widget to run the custom action when clicked. If you do this, you can add your own custom icon for the control, as described here, and it will be displayed with the other controls, below the widget title.

Sam Duncan · Jul 23, 2018

Hi Karthik,

Can you provide any more information this error? What are you trying to do in DeepSee when the error occurs, and what other information is in the error message?

It might be easier to help you with this error if you open a WRC issue. Please feel free to do that by emailing support@intersystems.com or calling +1 617 621-0700 if you think that would be helpful.

Sam Duncan · Jul 6, 2018

Hi José,

Yes, the filterSpec URL parameter is required, according to the documentation here.

It looks to me like the /Info/FilterMembers service expects to get a single level (of a specified dimension and hierarchy) as the filterSpec. Although the level names are the same for the two LevelCs, they are unrelated as far as the REST service is concerned because they are in different dimensions and hierarchies.

I don't know exactly what you are trying to do with this combined list of filter members, since it may not be an accurate list of the members of either level if some items appear in one but not the other. In terms of creating the list, though, you could try running /Info/FilterMembers once for each of the two levels, and writing code to combine the result sets while removing duplicates.

Sam Duncan · May 31, 2018

One thing to keep in mind when creating a hierarchy is that each member of a lower level in the hierarchy must correspond to a single member of each higher level. For instance, in the hierarchy you propose, if you have prefectures named PrefA and PrefB, you would need to make sure that there isn't a Comisaria named Com1 in both PrefA and PrefB, and so on.

One possible way around this, if you notice that this could be a problem, is to include information from the higher levels in the members of the lower levels, so that your Comisaria members are named PrefA-Com1 and PrefB-Com1, for example. In this way, each Comisaria member will belong to only one Prefecture.

This is related to the issue discussed here (Lexi Hayden's comment in particular is useful): https://community.intersystems.com/post/tips-tricks-be-aware-month-week-hierarchy-deepsee

I'm not sure whether the four fields in your sample data correspond to the four levels you want to include in the hierarchy. If so, though, it would be a problem to put UNI_TIPOUNIDAD below UNI_DESCRIPCION in a hierarchy, because the member "50" of the UNI_TIPOUNIDAD level would correspond to both the "38A. COM. PUENTE ALTO" and the "1RA. COM. ARICA" members of the UNI_DESCRIPCION level.

Sam Duncan · Oct 24, 2017

Hi Lin,

You can export shared calculated members and other DeepSee folder items to a container class, which will hold a version of those items in XML format. You can then import the folder items from the container class into the new environment. The documentation on this topic is here: http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

Please let me know if you have any questions.

Sam Duncan · Jul 3, 2017

Hi Jaqueline,

This Developer Community post has some information that you may find useful: https://community.intersystems.com/post/deepsee-period-date-vs-same-peri...

It deals specifically with comparing results for this year to date versus the same time period in the previous year, but you might be able to apply some of the same concepts when writing your MDX expressions. Let me know if you need clarification, or if this doesn't enable you to make the calculations you intend.

Best,

Sam Duncan