No Problem.  The newer JSON handling is quite flexible (Dynamic Objects).  When you move to IRIS you also get the %JSON.Adapter class.  Add that to the inheritance of any class and you get extend that flexibility to whole object structures.

I don't think there is any option to do this.  By executing this again from the command line you are indicating that you want to open CStudio.

Why not just use the File (menu) -> Open?  in CStudio and navigate to the class you want.

If you used package mapping you may have forgotten to map the global too.  Examine the class definition to find the global name to map.  If you map the class, but not the global you are getting the code of the class, but the storage would be local.  This allows the sharing of definitions across namespaces without sharing the data.  Add the global mapping to share the data too.

Dmitry,

The method of logging to a global was primarily to match the original use case.  Having a full class for logging including indexes would be a better option.

However, my personal belief is that suspending transactions, or even worse stopping and starting  journaling,  is not really a good option.  Even if the actually coding does not appear to be complex there is the potential for reach beyond the current transaction if you don't cover all bases.  Holding the logs in a temporary global that then gets written out after the transaction insures that the application logic is intact.  You could even encapsulate this functionality in classmethods.  If there is any failure the impact would be on the logging and not the actual logic of the transaction.

Not if we could perform an update/insert/save that could be intentionally and deliberately excluded from the transaction OR if the suspend was only for the current transaction so no lasting impact was even possible then I would feel more comfortable with that approach.

I will add that this is a matter of design and the programmer's approach.  Either method works the decision is where you wish to have any risk, no matter how small that risk is.  My preference is to be absolutely sure the integrity of the transaction  is maintained over the logging.

First let me state for clarity that the life of a transaction should be short.  That is a single logical transaction to the application.  I have seen cases where an entire batch update was treated as a single transaction.  This can create many problems that are not easy to diagnose.

I also agree with Fabian that suspending transactions is a path that can lead to complexity in the code that it best to avoiding.  The nature of a transaction is to track EVERYTHING that happens in the transaction.  Messing with that will lead to issues with maintainability and debugging later in the life of the application.

My suggestion is to do your logging to an in-memory global while in the transaction.  Then you can permanently write this after the transction commits or rolls back.   Two things to be sure of in this method: 

1. always explicitly commit or rollback the transaction.   Don't rely on implied rollback that would occur from a process end
2. enclose your transaction in a try/catch block.  This will insure that you have the opportunity to commit your logs in the case of a system fault.  This could be an existing try/catch in the program.  However for control and clarity I recommend a separate try/catch for the transaction.

How you commit your log updates will depend on your error handling.  I this example the logs are committed in two places, after a tcommit and in the catch block since the catch block will throw the exception up the stack.  If this did not occur then a simpler approach would be to write the logs out after the catch block.  

Example (just typed it here for example.  Not a running program) with exception passed up the stack

Try {
    set ^LOG($Increment(^LOG)) = "starting a transaction"
    TSTART
    // do some program logic
    // do some logging
    set tLog($Increment(^LOG)) = "some application trace" // note using the still using he ^LOG increment
    
    // if application error
    throw ##class(%Exception.StatusException).CreateFromStatus(tSC)

    TCOMMIT
    Merge ^LOG = tLog
} catch except {
    TROLLBACK
    Merge ^LOG = tLog
    Throw except
}
 

Example with internal error handling only

Try {
    set ^LOG($Increment(^LOG)) = "starting a transaction"
    TSTART
    // do some program logic
    // do some logging
    set tLog($Increment(^LOG)) = "some application trace" // note using the still using he ^LOG increment
    
    // if application error
    throw ##class(%Exception.StatusException).CreateFromStatus(tSC)

    TCOMMIT
} catch except {
    TROLLBACK
}
Merge ^LOG = tLog
 

Murray,

This looks great.  However I am having a problem getting this to work with a recent pButtons report I received.  The error is a follows.  Any thoughts?

docker container run --rm -v "$(pwd)":/data yape/yape --mgstat --vmstat -c /data/dbmirror2-c_CACHE_20190131_161057_24hours.html
INFO:root:Profile run "24hours" started at 16:10:57 on Jan 31 19.
Traceback (most recent call last):
  File "/usr/local/bin/yape", line 11, in <module>
    load_entry_point('yape', 'console_scripts', 'yape')()
  File "/src/yape/yape/command_line.py", line 6, in main
    yape.yape2()
  File "/src/yape/yape/main.py", line 248, in yape2
    parsepbuttons(args.pButtons_file_name, db)
  File "/src/yape/yape/parsepbuttons.py", line 382, in parsepbuttons
    StartDateStr = datetime.strptime(StartDateStr, "%b %d %Y").strftime(
  File "/usr/local/lib/python3.7/_strptime.py", line 577, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/usr/local/lib/python3.7/_strptime.py", line 359, in _strptime
    (data_string, format))
ValueError: time data 'Jan 31 19' does not match format '%b %d %Y'
 

If that is the case you can use BPL to create a business process with greater control over the orchestration.  You would set it up so that it  sends to each end point synchronously so that the first send has to happen before the second.  Of course if this were the case then the receiving side, with separate end points, would have to be sure that the messages stayed in order.  That is out of your control however.

I would say that this is definitely not recommended.  It does violate the intent of the object design.  You are probably not privy to why this was marked private and internal.  Providing a method to bypass that could create problems.  Of course if this is only for debugging a class that you don't have the ability to edit it may be acceptable.

John,

I thought I would add another example to this as  I have never needed to use the control wrapper solution.  I found I had to add gzip as an installed package in my docker file.  Below is a docker image built for centos.  The installation is HealthShare rather than Cache, but the that is just a change in the InterSystems installer referenced.   The overall process should work with value that make sense for your environment.  One  very important change is that the entry point should be ccontainermain.  The reason for this is the entry point needs to stay running to keep the container up and running.  Ccontrol will start Cache then end which will actually exit and shutdown the container.  There is a link to where to find this program at https://community.intersystems.com/post/cache-db-docker-container

# pull from this repository
# note that if you don't have the distribution you're after it will be automatically
# downloaded from Docker central hub repository (you'll have to create a user there)
#
FROM centos:latest

# setup vars section___________________________________________________________________
#
ENV TMP_INSTALL_DIR=/tmp/distrib

# vars for Caché silent install
ENV ISC_PACKAGE_INSTANCENAME="HSPI" \
    ISC_PACKAGE_INSTALLDIR="/opt/intersystems/healthshare" \
    ISC_PACKAGE_INITIAL_SECURITY="Normal" \
    ISC_PACKAGE_CLIENT_COMPONENTS=""  \
    ISC_PACKAGE_USER_PASSWORD="xxxx" \
    ISC_PACKAGE_CSPSYSTEM_PASSWORD="xxxx" \
    ISC_PACKAGE_HSMODULES="coretech,hscore,mprl,hspi"

# distribution file________________________________________________________________
# set-up and install from distrib_tmp dir
RUN mkdir ${TMP_INSTALL_DIR} && \
    mkdir -p ${ISC_PACKAGE_INSTALLDIR}/mgr
WORKDIR ${TMP_INSTALL_DIR}

# update OS + dependencies & run silent install___________________________________
RUN yum -y update && \
    yum -y install tar gzip which java-1.8.0-openjdk

ADD HealthShare-2018.1-Exchange_Insight_Index-b7718-lnxrhx64.tar.gz .

RUN ./HealthShare-*/cinstall_silent && \
    rm -rf ${TMP_INSTALL_DIR}/* && \
    ccontrol stop $ISC_PACKAGE_INSTANCENAME quietly 
COPY cache.key $ISC_PACKAGE_INSTALLDIR/mgr/

# TCP sockets that can be accessed if user wants to (see 'docker run -p' flag)
EXPOSE 57772 1972

# container main process PID 1 (https://github.com/zrml/ccontainermain)
WORKDIR /
ADD ccontainermain .

ENTRYPOINT  ["/ccontainermain","-cconsole","-i", "HSPI"]

Yes that would be a good course. There is a date coming up on April 8th.  In the meantime the online learning can get you started.  You should be able to accomplish quite a bit without any programming. Where you will need to do some is in creating a message class to contain the extracted data that is to be sent to SQL Server and to create the actual SQL operation to update SQL server.  Neither is difficult to do.  I would definitely suggest engaging with your InterSystems Sales Engineer for guidance.

Not to worry.  You don't need to do C# programming or deal with obscure libraries.  With Ensemble you can accomplish much of what you need to do without alot of programming. I would start with the "Build your first HL7 production" learning path to discover how to create an HL7 integration.  There is also Classroom training that you can sign up for.  Check our learning services site for class schedules.

To update SQL Server you would create a Business operation (which will require some coding using ObjectScript) that uses our SQL Outbound adapter to update SQL Server.  Here is a link to that documentation.  Using the SQL Outbound Adapter

Finally, if you need more direct assistance I would recommend engaging with the Sale Engineer assigned to your account.   We're always here to help get you moving in the right direction.