Hats off to you Sean! You did a great job pulling all of this together!
Not sure if it is worth listing or not, but here is an *ancient* open source app written in Caché which may still be interesting to some people:
http://onforme.sourceforge.net/
https://sourceforge.net/projects/onforme/
(not guarantees that it will work out of the box with current versions of Caché ;) )
Check out the full tutorial which includes REST API set-up:
https://community.intersystems.com/post/lets-write-angular-1x-app-cach%…
What is your browser and version? Is it by any chance Firefox 57.0?
EDIT: Nevermind - I see that you said Studio ate all of the licenses, so unless you are launching pages in a web browser from Studio my hunch probably isn't correct
I completely agree - this would make the results much more helpful!
You can do this via the following (it is a little hidden):
Studio > File > Change Namespace > Connect > (select instance) > Enter credentials and uncheck "Remember Password"
Could you please give this a try and let us know if it works for you?
Glad to hear it is working!
Could you please mark the Answer below as accepted so that people know that it worked?
Thanongsak,
Apologies for the delay - the Developer Community is having issues with its email update logic so I had no idea you asked this question.
This image is currently internal to InterSystems as it's for the InterSystems IRIS Data Platform which is in early adopter mode. Contact your Sales Rep in order to get access to the program and to InterSystems IRIS. It will be made publicly available early next year.
Thanks!
Ben
You can run this from Caché Terminal, or put it in a routine or class and run it:
USER>Set httprequest=##class(%Net.HttpRequest).%New()
USER>Set httprequest.Server="www.intersystems.com"
USER>Do httprequest.Get("/")
USER>Do httprequest.HttpResponse.OutputToDevice()
HTTP/1.1 301 Moved Permanently
CONNECTION: keep-alive
CONTENT-LENGTH: 178
CONTENT-TYPE: text/html
DATE: Thu, 12 Oct 2017 14:21:23 GMT
LOCATION: https://www.intersystems.com/
SERVER: nginx
X-TYPE: default
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
I have received a stream before as follows in my WebService client:
Method MyWebMethod(pAction As %String = "", ByRef pFile As %FileCharacterStream = "", ByRef pDataSet As %XML.DataSet = "") As %xsd.base64Binary [ Final, ProcedureBlock = 1, SoapBindingStyle = document, SoapBodyUse = literal, WebMethod ]
{
...
}
I am able to use this method signature to both receive files from the web service as well as send files to the web service.
Hope that helps!
Ben
Great tip - thanks John!
Ah .... by default, you might find that the REST service used by Atelier is set to Unauthenticated:
/api/atelier
We have found that we need to make sure that this is configured for "Password Authentication" in order for our server-side source control hooks to operate properly.
Studio Source Control (aka Server-side Source Control hooks) are supported if you are using against DBs with version 2016.2 or greater. If you are one one of these versions and are having issues, I suggest you contact the WRC.
For more details on using Server-side hooks with Atelier, check out this presentation from the Global Summit:
https://learning.intersystems.com/course/view.php?id=713
NOTE - you need to make sure that your DB version has CDS2924 in it in order to protect against a serious bug which would allow Atelier to overwrite things which a user has not checked out of source control. This will be included in 2017.2.0, 2017.1.2 and 2016.2.3, or you can request it in an Adhoc from the WRC if required.
Thank you!! Much better :)
Personally, I agree with Tyler that their current location is a distraction. Can we move them after the comments or to the sidebar?
It is possible that no one was clicking on them in the side bar because they were not truly relevant....
You are most welcome - good luck!
Last thought - depending on the data that you have in your system and how exposed the server is, one possible solution is to create a new web application which only allows the Dashboard viewer to be served up, and then uses "Matching Roles" feature to look for a certain role that people needing this dashboard should have, and assigning the elevated privs required to see the dashboard to the Web App. This would allow you to give access to people without having to broadly expand their assigned privileges. Depending on how much you have to give them in order for them to see the dashboard, this may be something that you want to consider.
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.
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.
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 :)
What is the URL for this page? I can't seem to find it in my Ensemble instance.
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:
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).
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?
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!
Done - I raised enhancement request #148598. We'll see what gets decided on this.
Good times Robert - thanks for the memories :)
The following article (and it's ensuing discussion) may also be of interest to everyone:
https://community.intersystems.com/post/studio-tip-running-cos-commands…
HTH,
Ben
A colleague pointed out another option which is fairly complete already:
https://github.com/intersystems-ib/cache-git-studio
I played with it and would recommend it!
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!
w $system.Version.GetNumber() will get you just the version number string
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
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?