发布新帖

Encontrar

公告
· 九月 2, 2024

The 2nd InterSystems Japan Technical Writing Contest!

Hello developers!

Last year, for the first time, we held the Technical Article Contest on Japan's InterSystems Developer Community, and 📣 we are holding it again this year!📣

The topics are the same as last year, and you can submit any content related to InterSystems IRIS/InterSystems IRIS for Health.

🖋 InterSystems Japan Technical Article Contest – 2024: Articles related to IRIS 🖋

🎁 Participation prize:Everyone who submits a post will receive our👚Developer Community’s original T-shirt👕!!

🏆 Special Prize:Authors of three selected works will receive special prizes.

Updated on 30/8: Prize information added!Please check it out!👇

讨论 (0)0
登录或注册以继续
问题
· 八月 30, 2024

Only load part of XML/ SQL Snapshot in visual trace- portal loads too slow

As part of fully decoupling code we send a snapshot from a business service (running a SQL statement). 

sql service                         Processor                                File Out

This is picked up by a processer and puts it into a file .txt. 

Issue is if you open it up via the SQL.snapshot message as this is 46,819 rows it'll take too long to respond to opening up the sql.snapshot in the message viewer when viewing the session if looking from the business service 

Is there any way to not have this xml open up in full in the portal? I.e. have a see more? 

I am aware this could just be in the BP but for me this is the correct integration setup- SQL service to pick up the data- process to do something with it (passed in the correct message type for it) and then sent to a file/ downstream. 

3 Comments
讨论 (3)2
登录或注册以继续
问题
· 八月 19, 2024

Question about PKI Configuration

Hello everyone,

I'm currently working on getting familiar with OAuth2, following this article. Since Part 2 involves using PKI, I decided to implement it as outlined in the article. However, I've run into an issue that I can't seem to resolve, and my searches on Google haven't yielded any useful results.

Here's a brief overview of what I've done so far:

Configuring the PKI Server:

  • Navigated to: System Administration > Security > Public Key Infrastructure > Configure Local Certificate Authority Server.
  • Filled in all the required fields and saved the configuration.

As far as I can tell, this step was successful. The following three files were generated, and the message displayed was:

"Certificate Authority server successfully configured. Using existing files: D:\CacheSys\mgr\root_ca.cer, .key, and .srl."

Configuring the PKI Client:

  • Navigated to: System Administration > Security > Public Key Infrastructure > Configure Local Certificate Authority Client.
  • Again, I filled in all the necessary fields and saved the configuration.

 

This also seemed to work fine. The message after saving was:

"Certificate Authority client successfully configured."

Submitting a Certificate Signing Request:

  • Navigated to: System Administration > Security > Public Key Infrastructure > Submit Certificate Signing Request to Certificate Authority Server.
  • Filled in all the required fields and saved the configuration.

However, now I'm seeing the following error message:

"ERROR #5002: ObjectScript Error: <WRITE>Send+122^%Net.HttpRequest.1"

 

The auth.csr and auth.key were nevertheless created.

I’m not sure how to interpret this error message. If anyone has any insight into what might be missing or where the problem lies, I would greatly appreciate your help.

maybe also important:

Below are the SSL settings for the CA Test Server:

 

Thank you in advance for your assistance.

Best regards,
Daniel Goerke

1 Comment
讨论 (1)2
登录或注册以继续
文章
· 八月 16, 2024 阅读大约需 4 分钟

TestCoverage Embedded Python and UI

Two big changes for the TestCoverage open source tool: Embedded Python support, and a new UI 

Embedded Python

Previously, TestCoverage could only track unit test coverage for code written in ObjectScript. It would ignore code written in other languages like Python in the coverage statistics.

 

As more and more IRIS application code is being written in Embedded Python instead of just ObjectScript, it's critical that TestCoverage can include coverage results for Embedded Python code. Customers (through the TestCoverage GitHub issues) as well as others in InterSystems have expressed interest in seeing Embedded Python support.

 

The user still installs and runs TestCoverage the same way as before, as described on the TestCoverage GitHub. The coverage results for Embedded Python code now get included in the aggregate coverage statistics as well as the individual line coloring, as displayed in the above example. 

Under the hood, the Embedded Python coverage is tracked using Python's sys.settrace tracer, independently of ObjectScript's %Monitor.System.LineByLine, and then the results are combined and displayed together. This can cause very minor discrepancies in which lines are marked as executable (i.e. can be run at all). For instance, in the above picture, Python considers the elif statement as executable, but ObjectScript does not consider the ElseIf statement as executable. At the end of the day, any line of code marked red was not covered, and any line of code marked as green was still covered; this just slightly affects which lines of code we ignore, which doesn't cause any problems. 

New TestCoverage UI 

The previous TestCoverage UI was an old Zen UI that didn't surface many of the useful statistics that TestCoverage tracks. In addition, TestCoverage could only be run from the command line. 

To solve these problems, we've created a new Angular UI building off of isc.perf.ui, the existing UI for interacting with the Line-By-Line Monitor (^%SYS.MONLBL). The web application comes with an accompanying REST API and WebSocket connection to retrieve data from the IRIS server. It also fixes the previous user authentication for isc.perf.ui, so that it now uses standard IRIS login/logout. This is also publicly available on the Open Exchange, under the name isc-perf-ui. Below are some of the new UI's features and uses. 

Installation

There are some additional steps for installing isc.perf.ui if you want to use the new TestCoverage features. On Windows only, you need to enable the IIS WebSocket protocol. On any OS, you need to give a specific user (usually CSPSystem) a resource permission (usually %DB_User) in the IRIS management portal. These steps are described on the isc-perf-ui GitHub page

Test Coverage Page

On the Test Coverage page, you can select the parameters that you want to run TestCoverage on your unit tests with.

  

The parameter explanations include descriptions of what each of these parameters control. You can also click into an input box to see a sample value, and there's input validation to make sure that your inputs are in a valid format.

After you press submit, the call to run TestCoverage will begin, and you'll see live progress of your unit tests in the log at the bottom of the page. 

 

After the tests have finished running, the dropdown select menu on the right should open with a list of routine + test path combinations, as well as the overall coverage percentage for your code and the link to the results of the unit tests themselves.

 

Click on any to be taken to the coverage results page for that routine under that unit test directory.

Here, you can see which lines of code were covered by your unit tests according to TestCoverage. There are also additional metrics like TotalTime, which tracks the amount of time the code spent on a certain line of code from its start to finish. 

 

You can further sort in ascending or descending order by clicking on the arrows next to the headers; this is a useful way to see which lines of code take the longest. 

 

Finally, the Show Methods button opens up a table with the cyclomatic complexity of each of your methods, showing which methods are the most complex and vulnerable to bugs. 

 

When you're done, can click the back button to go back to the launcher page. The red clear results button lets you clear all your test coverage runs.
 

Historical Coverage Page

After clicking on a specific past Run ID, you can view the class-level coverage results (line coverage, method coverage, timing) for all the classes in that run. This is the same data as the main results page from TestCoverage. This table is also sortable by each column. 

 

Again, both tools are available on the InterSystems Open Exchange (isc-perf-ui and Test Coverage Tool) and on GitHub. Good testing to everyone! 

  

4 Comments
讨论 (4)3
登录或注册以继续
公告
· 八月 7, 2024

Do you use client-side editing in VS Code? If so, we want your feedback!

The VS Code extension development team is looking for beta testers to provide feedback on a proposed overhaul of the client-side editing workflow. The full list of changes can be found in the GitHub pull request description. Here are the highlights:

  • Support the use of client-side editing in any non-isfs workspace folder, not just folders in your local file system. For example, with VS Code Remote Development.
  • Create an index of all Classes, MAC and INT routines, and Include files inside non-isfs workspace folders. This will be used to determine the URI of classes and routines (for example, for Go To Definition).
  • Automatically sync all file changes, creations and deletions in client-side workspace folders with the connected server. This can be turned off using the new objectscript.syncLocalChanges setting. This new setting replaces the old objectscript.importOnSave setting, which is no longer needed. If objectscript.importOnSave was set to false, the extension will set objectscript.syncLocalChanges to false upon activation so no user migration is required.
  • Automatically show and hide the InterSystems Explorer and Projects Explorer views based on the folders in the workspace. InterSystems Explorer is only shown if there is at least one non-isfs workspace folder. Projects Explorer is only shown if there is at least one isfs folder. This replaces the objectscript.showExplorer setting.
  • Change the default value of the objectscript.explorer.alwaysShowServerCopy setting to true. The InterSystems Explorer should always show the server copy since the local copy can be opened from the files explorer.
  • Change the default value of the objectscript.autoAdjustName setting to false. Now that we have an index of the workspace, we no longer require that a document's name match the file path for the extensions to find it.
  • Cache the list of Studio Abstract Document extensions that are supported for each server connection so we can properly import them from client-side folders. Importing abstract documents is now independent of the objectscript.export settings, except for DFI’s which still check the export settings to preserve the current path-splitting behavior. Any file within a workspace folder that has a supported abstract document extension will be imported with the last part of the path used as the server name (except for DFI’s that match the export settings). For example, if the file path on disk is /src/other/example.ext, the server name will be example.ext.

In addition to general feedback on the changes, there are four design questions that have yet to be answered:

  1. Do any users want the InterSystems Explorer (NOT the default VS Code file explorer) to show the local copies of the documents? If not, the objectscript.explorer.alwaysShowServerCopy setting can be removed. EDIT: This setting will be retained for backwards compatibility.
  2. Do any users edit DFI files locally and have repositories that depend on the folder splitting behavior? If not, that special handling will be removed and DFIs will be treated like any other Abstract Document type. EDIT: This behavior will be retained for backwards compatibility, but newly exported DFI files will not be split into subfolders.
  3. Should the automatic deletion of files on the server when the local copy is deleted be guarded by a setting so users can disable it? EDIT: This is covered by the new objectscript.syncLocalChanges setting.
  4. This extension has a feature that will attempt to adjust the name of a class or routine when it's copied or moved to a new location within the workspace folder. This was implemented to help developers keep the file path and document name in sync. It can be turned off using the objectscript.autoAdjustName setting. Do users value this feature? Should the objectscript.autoAdjustName setting be set to false by default? Should this feature be removed entirely since the document index removes the need for the path to match the document name? EDIT: This setting's default has been changed to false.

Here's how you can share your feedback:

  1. Download the zip file at the end of this post and extract the vsix file contained within.
  2. Install the vsix file in VS Code using these directions, or by dragging the file from your file explorer into the Extensions view in VS Code.
  3. Follow your normal development workflow and try out some new features.
  4. Share your experience here, or on the GitHub pull request.

Thanks in advance for trying this out and we hope you like the changes!

vscode-objectscript-2.12.11-dev.1401.vsix.zip

35 Comments
讨论 (35)10
登录或注册以继续