User bio

Born on April 2, 1980. Married, 1 child.

Bachelor's degree in Information Systems.

Dynamic and proactive, he works collaboratively in teams, always seeking knowledge and challenges.

A knowledge disseminator, he is always engaged in the team's mutual growth, prioritizing the continuous evolution of knowledge and always applying best practices.

Certified in InterSystems technologies.

Experienced professional in systems architecture, solutions, and systems interoperability, with over 20 years of experience in complex, large-scale projects across various sectors, including healthcare, automotive, oil and gas, and financial services.

I have a proven track record of success in defining software architectures, leading development teams, and delivering innovative solutions that meet business needs.

I am capable of working with a wide range of technologies and platforms, and I have a strong commitment to quality, efficiency, and value delivery.

Skills:

  • Solution Architecture: Defining reference architectures, design patterns, system modeling (UML), service-oriented architecture (SOA), microservices, event architecture.
  • Software Development: Java, C#, Python, JavaScript, SQL, COS (Caché Object Script), R.
  • Systems Integration: InterSystems (IRIS, Health Connect, Ensemble), HL7, FHIR, REST, SOAP, Mule Soft.
  • Databases: SQL Server, Oracle, InterSystems Caché/IRIS, MongoDB.
  • DevOps: Docker, AWS, Azure.
  • Methodologies: Agile (Scrum, Kanban), Waterfall.
  • Business Intelligence: Tableau, Power BI, TIBCO Spotfire, SAP BusinessObjects.
Show all
Member since Dec 8, 2015
Replies:

Hi @Aziz Cotrim,

During development, to debug the entire BS->BP-BO integration flow, I set the INVOCATION parameter of both BP and BO to InProc. This way, execution occurs in the process that created the first message sent, in this case, BS.

I create a debugging routine or class method where I instantiate BS and continue debugging from there.

Below is a code snippet to start the debugging process from a BS.
 

ClassMethod Debug()
{
    Break
    #Dim bs As Ens.BusinessService = ""
    #Dim statuscode As %Status = ##Class(Ens.Director).CreateBusinessService("BS Name", .bs)
    If ($System.Status.IsError(statuCode))
    {
        Write "Error creating a BS instance: ", $System.Status.GetErrorText(statusCode)
        Return
    }
    Set statusCode = bs.ProcessInput(input, .output)
    If ($System.Status.IsError(statuCode))
    {
        Write "Error returned form ProcessInput method: ", $System.Status.GetErrorText(statusCode),  !
        Return
    }
}

For more information:
Invoking a Business Service Directly
Defining a Business Operation Class
 

Hi @Aziz Cotrim 
One approach I use, to take advantage of both what @Nick Petrocelli said and what @Yaron Munz said, is to create a message that will be the common basis for defining the properties. I define it as abstract and create specific messages inheriting from this base class, adding the %Persistent class to the inheritance list. This way, the storage will be individual for each message, but maintaining a single definition.
Take a look at my Interopway Rest project. I use this approach.

Open Exchange applications:
Certifications & Credly badges:
Followers:
Following: