Is your BS enabled via SDS by any chance? If yes, can you try enabling it directly and remove Enabled SDS to test?
- Log in to post comments
Is your BS enabled via SDS by any chance? If yes, can you try enabling it directly and remove Enabled SDS to test?
WebServerPort=0 only stops internal apache which has been removed many years ago. It does not affect an external webserver.
Change it in CSP.ini, leaving only your web app entry.
I suppose you can do it via Merge CPF too if you really want:
[Actions]
ModifyApplication:Name=/api/atelier,Enabled=0
ModifyApplication:Name=/api/deepsee,Enabled=0
ModifyApplication:Name=/api/docdb,Enabled=0
ModifyApplication:Name=/api/healthshare-rest/hssys,Enabled=0
ModifyApplication:Name=/api/iam,Enabled=0
ModifyApplication:Name=/api/iknow,Enabled=0
ModifyApplication:Name=/api/interop-editors,Enabled=0
ModifyApplication:Name=/api/mgmnt,Enabled=0
ModifyApplication:Name=/api/monitor,Enabled=0
ModifyApplication:Name=/api/security-config,Enabled=0
ModifyApplication:Name=/api/uima,Enabled=0
ModifyApplication:Name=/csp/broker,Enabled=0
ModifyApplication:Name=/csp/documatic,Enabled=0
ModifyApplication:Name=/csp/fhir-management,Enabled=0
ModifyApplication:Name=/csp/fhir-management/api,Enabled=0
ModifyApplication:Name=/csp/fhirsql,Enabled=0
ModifyApplication:Name=/csp/fhirsql/api/repository,Enabled=0
ModifyApplication:Name=/csp/fhirsql/api/ui,Enabled=0
ModifyApplication:Name=/csp/healthshare,Enabled=0
ModifyApplication:Name=/csp/healthshare/hcc,Enabled=0
ModifyApplication:Name=/csp/healthshare/hcc/bulkfhir,Enabled=0
ModifyApplication:Name=/csp/healthshare/hcc/bulkfhir/api,Enabled=0
ModifyApplication:Name=/csp/healthshare/hcc/services,Enabled=0
ModifyApplication:Name=/csp/healthshare/hssys,Enabled=0
ModifyApplication:Name=/csp/healthshare/hssys/app,Enabled=0
ModifyApplication:Name=/csp/healthshare/hssys/app/api,Enabled=0
ModifyApplication:Name=/csp/healthshare/hssys/services,Enabled=0
ModifyApplication:Name=/csp/hscustom,Enabled=0
ModifyApplication:Name=/csp/hssys,Enabled=0
ModifyApplication:Name=/csp/oauth2-client/api,Enabled=0
ModifyApplication:Name=/csp/oauth2-server/api,Enabled=0
ModifyApplication:Name=/csp/sys,Enabled=0
ModifyApplication:Name=/csp/sys/exp,Enabled=0
ModifyApplication:Name=/csp/sys/mgr,Enabled=0
ModifyApplication:Name=/csp/sys/oauth2,Enabled=0
ModifyApplication:Name=/csp/sys/op,Enabled=0
ModifyApplication:Name=/csp/sys/sec,Enabled=0
ModifyApplication:Name=/csp/test,Enabled=0
ModifyApplication:Name=/csp/user,Enabled=0
ModifyApplication:Name=/isc/studio/rules,Enabled=0
ModifyApplication:Name=/isc/studio/templates,Enabled=0
ModifyApplication:Name=/isc/studio/usertemplates,Enabled=0
ModifyApplication:Name=/ui/interop,Enabled=0
ModifyApplication:Name=/ui/security-config,Enabled=0Thank you, Stephen!
What's your Business Process class?
If you're using a message router (derived from EnsLib.MsgRouter.RoutingEngine), check Response From, Response Target Config Names, and Forward Generated Response To Target(s) settings. Although if called in a sync way, it should return a response to the caller anyway.
If you're extending an Ens.BusinessProcess, you can populate a response in any On* method (OnRequest, OnResponse, OnComplete, etc.)
If you're writing a BPL process, you should be able to access a response object everywhere.
Thank you, Brett!
First ^UnitTestRoot must be set to a valid directory. This resolves the initial error of:
LogStateStatus:0:Finding directories: ERROR #5007: Directory name 'U:\internal\testing\unit_tests\' is invalid <<==== **FAILED** (root)::
After that run:
Do ##class(%UnitTest.Manager).DebugRunTestCase(,"User.TestCase")
List several classes separated by a semicolon (;) to run them as one suite:
Do ##class(%UnitTest.Manager).DebugRunTestCase(,"User.TestCase;User.TestCase2")
I was confused a bit by the practice question 19
check whether the caller correctly passed an instance of
Sample.Personor a subclass.
I thought it meant:
check whether the caller correctly passed an instance of
Sample.Person(which would be correct) or a subclass (which would be incorrect).
But it meant:
check whether the caller correctly passed an instance of
Sample.Personor a subclass (both would be correct).
This can possibly work if you make %Persistent a secondary superclass. In that case, new properties would go to a separate subscript, and your setup can maybe work (requires testing).
Storage works like this (parent has N properties, Child - X):
Child Extends %Persistent, Parent:
^a(id) = $lb("", prop1, prop2, ..., propX)Child Extends Parent, %Persistent:
^a(id) = $lb("Child", propA, propB, ..., propN)
^a(id, "Child") = $lb(propO, propP, ..., propX)Anyone? Found this idea.
I use return where it's important that we exit (middle of the loop, etc) immediately, in all other cases I use quit.
I think you might want to track these numbers instead:
I wouldn't worry about total class length, but rather the number of individual elements and method sizes.
There's also class limits docs, but if you hit them, you probably have an issue already.
To wait for 15 seconds:
Set tSC = ..SetTimer("PT15S")I'm thinking we may need to create a custom business operation extending the default one EnsLib.HL7.Operation.TCPOperation, and we would need to wrap up the RetryCount inside the response. What do you think?
I think you are correct. RetryCount is a runtime property, I don't think it's stored anywhere longterm, so you need a custom BO to save it. There are some workarounds you can attempt:
But I would definitely recommend subclassing.
Great tutorial, but please consider adding IAM policies/roles jsons.
Check ParseIOStream/ParseFramedIOStream from EnsLib.HL7.Parser. These methods take a stream (read to a specific position) and return next HL7 message. Overall loop can be seen in EnsLib.HL7.Service.FileService's OnProcessInput.
Great! What's the new database size limit?
Circular dependency possibly? I'd recommend outputting dynamic object on every pass.
Awesome!
However, it is often difficult to test just the REST API without inadvertently involving the authentication scheme, the web application configuration, or even network connectivity. Those are a lot of hoops to jump through just to test the code within your dispatch class.
Another way you can do this is by splitting web (rest) api from the business logic. I think ideally your REST handler method does only the following two things:
This way you can focus on unit testing your underlying api layer and keep the REST parts of your implementation as simple as possible.
You can use BPs to do that automatically.
BS (pool size 1) sends file to BP (1 request, pool size 1).
BP parses the file and sends X async requests to BO (pool size >1) for processing, total request count is stored in BP.
BP OnError/OnResponse methods are called once rows are being processed, maintain count here.
Once OnError/OnResponse count matches original count send a final batch request.
a-z, A-Z only. Everything else is considered non-alphabetic, although I guess non-latin characters would be a more correct term.
Yes, it's fewest characters.
PS: why is the correct result in the testNumbers method
321and not 213?
Thanks for noticing! Fixed.
Check out %GetSetting implementation in Ens.Config.DefaultSettings:
// Look in table starting with most specific match
If $D(^Ens.Config.DefaultSettingsD(pProductionName,pItemName,pHostClassName,pSettingName),data)
|| $D(^Ens.Config.DefaultSettingsD("*", pItemName,pHostClassName,pSettingName),data)
|| $D(^Ens.Config.DefaultSettingsD(pProductionName,"*", pHostClassName,pSettingName),data)
|| $D(^Ens.Config.DefaultSettingsD("*", "*", pHostClassName,pSettingName),data)
|| $D(^Ens.Config.DefaultSettingsD(pProductionName,pItemName,"*", pSettingName),data)
|| $D(^Ens.Config.DefaultSettingsD("*", pItemName,"*", pSettingName),data)
|| $D(^Ens.Config.DefaultSettingsD(pProductionName,"*", "*", pSettingName),data)
|| $D(^Ens.Config.DefaultSettingsD("*", "*", "*", pSettingName),data)
In your case your first setting would be resolved on line three:
$D(^Ens.Config.DefaultSettingsD(pProductionName,"*", pHostClassName,pSettingName),data)And your second setting would be resolved on line five:
|| $D(^Ens.Config.DefaultSettingsD(pProductionName,pItemName,"*", pSettingName),data)
But since line three resolves to a valid setting, line five would never be hit.
To work around that provide both item name and class name explicitly - it would be resolved on the first line for your outlier (since both item and class match) and the rest of the items would get their setting resolved on line three.
1️⃣ When you joined the Developer Community and how you first discovered it.
November 2015 not long after DC started. @Evgeny Shvarov told me about it.
2️⃣ A meaningful moment or story from your personal journey here.
I've been writing my Continuous Delivery series for seven years now! That's one of my longest writing projects.
3️⃣ An article, question, or discussion you consider especially valuable — one you believe others should take the time to revisit.
Lots of great stuff to find here on DC!
This post by @Guillaume Rongier is probably the one I revisited the most over the years.
This post by @Dmitry Maslennikov too.
This comment by @Timothy Leavitt (wrote an article based on that). Also this one - should be in product imo.
Try without the scripts, it should work asis.
Great article!
Interesting things you're doing.
Great article!
Highly recommend adding a common package root. I.e. not Operation.Alert but Company.Operation.Alert.
This way querying %Dictionary/InformationSchema becomes much easier since you always know what to filter on.
It will work with any HTTP request verb.
Most REST dev clients have support for HTML preview, just remember to set Content Type. I don't think swagger-ui can do that as it's not an app, rather a page running in a browser.