All
Accepted answers
Ben Spead · Sep 28, 2017 go to post

Did you turn on auditing in order to see what sort of a <PROTECT> is being thrown?

You may need to connect with the WRC if you're having a hard time finding the privs to give to the user.

Ben Spead · Sep 27, 2017 go to post

Thanks for this! I added an Answer which I think should work based on this information.

As email notifications seem to be having issues you may not have seen the answer yet.  When you do, please let us know if it works.

Ben Spead · Sep 27, 2017 go to post

Armin,

I took a quick look and the good news is that the Ensemble Management Portal is just wrapping a DS Dashboard.  This means that you can stick this in an iFrame in SharePoint (I think this is called the "Page Viewer Webpart") and point the source to the DeepSee Dashboard Viewer page with the Embed flag turned on.  E.g.  the following link works for me:

http://localhost:57772/csp/ensdemo/_DeepSee.UserPortal.DashboardViewer.zen?EMBED=1&NOBORDER=1&DASHBOARD=Ens%2FDeepSee%2FActivityVolumeAndDuration.dashboard

Based on your URL above, give this a try:

http://ntvensemble03/csp/activity/_DeepSee.UserPortal.DashboardViewer.zen?EMBED=1&NOBORDER=1&DASHBOARD=Ens%2FDeepSee%2FActivityVolumeAndDuration.dashboard

Report back and let us know if this works, and don't forget to "Accept" the answer if it does :)

Ben Spead · Sep 27, 2017 go to post

What is the URL for this page?  I can't seem to find it in my Ensemble instance.

Ben Spead · Sep 18, 2017 go to post

Ian - I completely understand why moving to Private Dev is challenging.  It is very much the nature of applications built on top of InterSystems technology, and it is certainly a challenge.  

You are absolutely correct in your thinking that you will see a lot of issues in trying to use Client-Side source hooks (especially for a distributed source control system like Git) against a Shared Dev instance.  I actually presented at Global Summit last week about the interplay between Client vs Serverside hooks and Private vs Shared Dev instances, and I recommended that people avoid the Client-Side / Shared Dev combination.  I would recommend that you download the slides and watch the recording of my session - you will probably find it to be very helpful:

Global Summit 2017: Shared Development for the 21st Century

As you are tied to Shared Dev workflow, I would strongly suggest that you consider using Server-side hooks to enable your dev workflow, and that you use a centralized Version Control System (VCS) like Perforce, Deltanji or Subversion rather than a distributed VCS like Git.  Serverside hooks will enforce the behavior of both Studio and Atelier, so you can still move to Atelier and still use this (just make sure that you are on 2017.2.0, 2017.1.2 or 2016.2.3 as those are the first versions that contain a fix to a hole that was recently found in serverside protections with Atelier).  

In terms of your code promotion question, please keep in mind that Atelier is a development tool and not a deployment tool.  As others have said, TEST and PROD should never have code pushed to it from Atelier but rather the code needs to come directly from your VCS.  I run internal app dev at InterSystems and our process looks like this:

  • Shared BASE, TEST and LIVE environments
  • Private BASEs for some apps
  • BASE, TEST and LIVE branches
  • VCS is Perforce
  • Serverside hooks on Shared BASE control concurrency and locking of items as they are being edited on Shared BASE
  • All check-ins include a logic identifier for the project (a Job in Perforce) 
  • When project is ready to move from BASE to TEST, we have a script that integrates all changelists with that Job from the BASE branch to the TEST branch
  • Changed items are pulled from TEST branch into TEST environment and compiled
  • Same process for moving things from TEST to LIVE

This process works very well for us and scales well on a variety of sized development teams (larger teams use more private BASE environments to prevent check-out collisions on Shared-BASE).  We've been working in this mode for about 7 years and it's really stabilized our environments and branches (compared to how things were before) and we're well positioned to move forward with Atelier in use side by side with Studio.

Hope this helps.  Please watch my Global Summit session and let me know if you have any questions (I plan to write a new article based on my session so feel free to jump in to the discussion there).

Ben Spead · Sep 15, 2017 go to post

Ian - the appropriateness of your architecture relies very much on whether or not there will be more than one developer working on this application and having access to these environments.  Can you please clarify that point?

Ben Spead · Sep 15, 2017 go to post

Ian,

If I were you, I would approach this as follows:

1) Baseline the code on all three of your servers using the "Caché UDL" project on GitHub

2) Use the PROD baseline to make your PROD branch/repot

3) Fork/Branch to make your TEST repo, and then check in your changes from TEST baseline on top of the changes integrated there from PROD

4) Do the same thing to make DEV - Fork/Branch from TEST and then check in your DEV Baseline on top of it

Now you should be positioned to integrate changes from DEV to TEST and deploy out of source control, and then the same from TEST to PROD.  This allows you to handle your merges within source control and not rely on merging from your IDE as part of a code push.

Side note - I expect you'll run into some frustrations trying to use client-side hooks against a shared DEV instance if you are not careful (I just did a presentation at Global Summit this past week which highlighted the challenges of that approach).  I would recommend that you move towards Private DEV instances as soon as you can, or if you intend to stay using a Shared DEV, then you might want to consider Server-side hooks instead (that being said - Git doesn't work very well in a shared dev type environment with serverside hooks, so this again points to the importance of moving towards private DEV instances as soon as you are able).  There will be several recordings from Global Summit which should be interesting to you on this topic - we'll be posting articles in the near future with the content so stay tuned!

Ben Spead · Sep 7, 2017 go to post

Done - I raised enhancement request #148598.  We'll see what gets decided on this.

Ben Spead · Sep 2, 2017 go to post

Please make sure to mark a response as an accepted answer once you are all set - it makes it helpful for others looking for an answer and prevents the 'unanswered' list from including things which have been resolved.

Thanks! 

Ben Spead · Aug 31, 2017 go to post

w $system.Version.GetNumber() will get you just the version number string

Ben Spead · Aug 30, 2017 go to post

Joel - the first paragraph says that eGit is installed with Atelier automatically but Nicole has confirmed that this is not the case.  Could you please edit the article and remove that statement?

Thanks!

Ben

Ben Spead · Aug 30, 2017 go to post

Thank you - I will take a close look!

How does Port.SourceControl.Extension.VCS relate to %Studio.SourceControl.Base?  None of the method names match so I am guessing that it doesn't extend it.  Would there be a different handling class extending the Source Control Base class which calls the method in your Git class?

Ben Spead · Aug 29, 2017 go to post

Thank you Rubens - that is very helpful! 

Could you please also post a Gist for Port.SourceControl.Extension.VCS?

Ben Spead · Aug 23, 2017 go to post

There is a huge benefit from two perspectives:

- If you need to refresh data in your Dev or Test environment, you can just grab the globals DB from Live and drop it in and not worry about overwriting any code in Dev or Test

- If you choose to deploy your code via a DB drop, you can drop in a new DB to replace the existing routines DB

NOTE - for either of these to work, you may need to map configuration into the routines DB (so you don't bring back Live config into Dev for instance)

HTH!

Ben

Ben Spead · Aug 8, 2017 go to post

Robert - thanks for posting, and it's great seeing that you're still doing awesome work in this space!

All the best,

Ben

Ben Spead · Aug 8, 2017 go to post

FYI ... we will have several sessions covering this topic at the Global Summit - attend if you can, otherwise check out the material afterwards!

For internal application development within InterSystems we use a variety of approaches, but the most common is as follows:

1) We use an internally developed issue tracking system, but we plan to eventually migrate to JIRA

2) We use Perforce for all of our source control 

3) We have BASE, TEST and LIVE environments for every application, typically BASE and TEST being cloned from VM snapshots of LIVE.  In addition to the Shared BASE VM, for those applications which are undergoing the highest rate of change, developers will create a local copy of the application to do their development work.  Some apps have all changes being developed on Shared BASE and the changes are progressed (via our Change Control tool) to TEST and the LIVE.  For applications where developers use Private BASEs, they commit there and then push the changes to Shared BASE and then to TEST and LIVE.

Feel free to ask questions (here or at Global Summit)!

Thanks for asking.

Ben Spead · May 22, 2017 go to post

Yes of course :)  Once you create a library of unittests you can script them to run automatically.  If you are using a continuous integration / build server then you can script the tests to run after the build has completed successfully.  We have some teams using Jenkins for this.  

Ben Spead · May 9, 2017 go to post

John,

If you haven't already done so, please contact the WRC to let them know how important it is to get the Production Class UI to respect source control hooks (I am with you all the way on this one, but Product Management needs to hear it from customers).

Thanks,

Ben

Ben Spead · May 9, 2017 go to post

John - if you haven't already done so, please contact the WRC and let them know how important it is to get the Production Class UI to respect source control hooks (I am with you all the way on this one, but Product Management needs to hear it from customers)

Ben Spead · May 5, 2017 go to post

Jennifer - Angular 2 is not supported by Angular Material.  By picking Angular 1.x Chris was able to demonstrate the stack selection that we're using for many internal applications as well as what many of our large customers are using (REST+AngularJS 1.x + Angular Material).

Ben Spead · May 4, 2017 go to post

Brendan - I think you are missing a ( in:

    do file.WriteLine(^Global1key))

Ben Spead · Apr 20, 2017 go to post

Kyle,

The macros are intended to prevent developers from having to refactor code at the same time as they perform an upgrade, as well as make it easier for application providers who have code running on a number of versions.

I've learned from experience that it is always best to have the fewest moving parts when possible when doing an upgrade so you can quickly find the cause of any issues that pop up.  Therefore, I always try to write forward compatible code and only after all of my systems for a given codebase have been upgraded and are stable do I start to introduce backwards incompatible changes.  These macros allow that very nicely.  In addition, using the macros means that you have more flexibility to upgrade without having to schedule a concurrent refactoring project (even if it is just a find and replace refactoring project :) ).

All that being said, the macros are not intended for long-term use with-in an application.  Once the 2016.1 > 2016.2 hurdle has been cleared then my recommendation would be to pull out the macros (find & replace) and stick with Caché's native JSON access going forward.  But that can then be a project that takes place post-upgrade, thus simplifying the upgrade and lowering risk.