All
Accepted answers
Ben Spead · Apr 25, 2018 go to post

Also, Classes lend themselves much better to programmatic access and manipulation of their content (you can do this with routines too but it is harder to do so due to their unstructured nature).

For example, the server-side Source Control hooks we use can programmatically insert an RCS Keyword as a class parameter ("SrcVer") into any class which doesn't already have it defined.   This is extremely powerful because it allows source control to create an automatic 'watermark' in every class created for our internal applications which can be programmatically access or from terminal:

SSO>write ##class(AppS.WebClient).#SrcVer
$Id: //custom_ccrs/us/ISCX/SSO/BASE/cls/AppS/WebClient.xml#6 $

This would require much more plumbing to do automatically with a routine!

Ben Spead · Apr 25, 2018 go to post

Making further changes to the SMP banner isn't supported unfortunately.  

Ben Spead · Apr 24, 2018 go to post

Kumar,

It sounds like you are trying to use Atelier with client-side source control hooks against a shared development instance - is this correct?  If so, you are bound to experience frustration with this due to consistency issues.

Please review https://learning.intersystems.com/course/view.php?id=713 which discussed the 4 modes of development, which are to be avoided, and options available to you in a summary graphic from the training:

If you are going to be using Atelier with client-side hooks, I *strongly* recommend you move to giving each developer their own private instance to test against.

Ben Spead · Apr 20, 2018 go to post

John - thank you for the update on this one.   The request# hadn't been on my radar but now it is and I am seeing what I can do to escalate internally (no promises though). 

Cheers,

Ben

Ben Spead · Apr 20, 2018 go to post

Kumar,

If you are using CCR then there are very specific  requirements in terms of development workflow which will provide assurances of no source loss, etc.  Please open a ticket with Support to discuss these specific concerns and considerations.

In summary, there can only be a single Disconnected BASE environments for each System, because the CCR Client Tools manage source concurrency within the Namespace, and if you have multiple BASE namespaces you have lost concurrency and therefore can lose source.  Atelier will work the same as Studio - you need a single Shared Dev Namespace using the CCR Client Tools (aka server-side source hooks) and at that point you can use either Atelier or Studio to edit the source in BASE.

IMPORTANT NOTE:  Server-side hooks will only work properly with Atelier if you are running a database version that includes CDS2924.  This is included in 2016.2.3+, 2017.1.2+ and 2017.2.0+ only.  If you are not sure if you have CDS2924 or not, please contact Support (if you use Atelier against a Shared Dev instance that doesn't have CDS2924 you don't have concurrency and therefore can lose source).

Hope that helps to get you started in the right direction :)

Ben Spead · Mar 8, 2018 go to post

You would also need to be careful of the following:

  •  integration endpoints (e.g. web service calls (especially those inserting data), POP3 mailbox retrieval, FTP fetches, etc)
  •  email generation code in your app
  •  task schedule
  •  NFS mount points

You must be very careful that your non-production instances do not behave as production post-cloning (e.g. you would never want a test system generating emails to non-developers).  We have all of our code-base instrumented so that with a single configuration global we can control production vs non-production behavior (including where to go for web service calls, etc).  This allows us to have identical code across all environments, but only Prod will send email, fetch actual user files, insert real data into other systems, etc.  We then have our application-specific configuration globals mapped to their own Config DB, which means:

  • when the Data DB is restored from LIVE it doesn't bring configuration data with it (i.e. we need to avoid a Test system suddenly thinking it is Prod because the global indicating Dev|Test|Prod is restored from Prod)
  • when we run a test build for CI on our Build servers (also cloned from Prod) we can start with an empty Code DB (and pre-populated Data and Config DBs) and everything "just works" :)

Glad to hear that you are already virtualized - that can really save you a lot of setup and config time.  Let me know if you have any additional questions :)

(P.S. Chris, welcome to the world of Caché and DeepSee!!  I hope you find the Community to be helpful.

note - if you are happy with this answer, please mark the Answer as Accepted so this thread falls off of the Unanswered Questions list)

Ben Spead · Mar 8, 2018 go to post

For my team we always deploy on VMs, which makes it trivial to clone the VM to create our Dev and Test instances (this helps ensure complete equivalent for all Caché settings, OS patch level, OS settings, etc).  When we moved to this approach it really helped to improve our testing stability and predictability (we have our Code and Data separated into different DB, so the Code DB is updated from source control and our Data DB can be updated weekly with restoring the backup of the Prod Data DB.

If you are currently deployed on bare iron this won't be an option for you.  But if you are virtualized for production (or can move to it in the future) you may find that it saves a lot of hassle for your Dev and Test instances.

Ben Spead · Mar 6, 2018 go to post

Alexey,

The post you referred to was with respect to license key changes - I didn't see any guarantees that a previous non-Ubuntu installs would be upgradable (in fact I would be surprised if they were).

I suggest you contact the WRC for final confirmation, but I expect you'll need to start with a fresh instance and move over your code, config and data.

Ben

Ben Spead · Jan 25, 2018 go to post

Geoffroy,

Welcome to Caché!  

Moving a database is really straightforward:

  1. Find the database definition in your 2007.1 instance in the System Management Portal
  2. Note the physical Directory where the cache.dat is located
  3. Shut down Caché and make a copy of the cache.dat file located in that Directory
  4. On your 2017.1 instance create a new database definition in the System Management Portal an point the Directory to the location of the copy of the cache.dat that you copied from your 2007.1 instance

Hope that helps!

Ben

Ben Spead · Jan 19, 2018 go to post

See this thread which discusses several options for server-side Studio hooks for Git:

https://community.intersystems.com/post/are-there-server-side-git-studi…

NOTE - in my use-case I was looking for server-side hooks in order to allow concurrent server-based development, and I discovered that Git is very poorly suited for that purpose.  I ended up abandoning Git and using Perforce instead for my demo (Perforce is very well suited for server-side hooks with concurrent server-based development).  If you are you already operating in a single-developer / single instance setup and if you can move to one of the very latest versions of the product (2017.2.0+ or 2017.1.2+) then you should take a look at Atelier with client-side source control hooks.

For a thorough review of the different development models (private instance vs shared instance) and the different source control hook approaches (client-side vs server-side), I highly recommend that you watch the following session from last year' Global Summit:

https://learning.intersystems.com/course/view.php?id=713

Ben Spead · Jan 4, 2018 go to post

Stephen,

An advantage to this is that the WRC will have a history of snapshots of your config and some basic operating data so that if you need to contact them about a performance issue, behavior change, etc, they could look back and see changes which have taken place in your system that might impact current behavior.  

Several large customers take advantage of this to make it easier to see trends in their instances.

HTH,

Ben

Ben Spead · Nov 21, 2017 go to post

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

Ben Spead · Nov 15, 2017 go to post

I completely agree - this would make the results much more helpful!

Ben Spead · Nov 3, 2017 go to post

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?

Ben Spead · Oct 30, 2017 go to post

Glad to hear it is working!

Could you please mark the Answer below as accepted so that people know that it worked?

Ben Spead · Oct 23, 2017 go to post

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

Ben Spead · Oct 12, 2017 go to post

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>
Ben Spead · Oct 11, 2017 go to post

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

Ben Spead · Oct 10, 2017 go to post

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.

Ben Spead · Oct 10, 2017 go to post

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.  

Ben Spead · Oct 2, 2017 go to post

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....

Ben Spead · Sep 28, 2017 go to post

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.