Testing requests to SOAP Webservices in Weblogic

Danilo Soares Cardoso — Sun, 26 Apr 2020 06:00:59 +0000

Every time when I work with a new technology, I like to read more about this stuff and do some experiments. When we work with development, this lead us to that way, learning with the pratice and day-by-day activies. One of the examples of this learning that I acquired in the last months was working with some new technologies in my career.

In the area that I am responsible for at TCS, one of the applications we care for is made in Java and runs on Weblogic, a server maintained by Oracle for Java EE systems. Something very interesting that I have been deepening in the last months dealing with Weblogic is the test of web services that it brings as standard, called Web Services Test Client.

This tool is very useful because it allows tests to be done quickly, without having to create mocks in SoapUI, for example. According to the official documentation, the Web Services Test Client is used to:

test basic functionality to test the correct operation of the 'deployed' webservice
basic security tests for authentication
view the web service WSDL
advanced tests, such as atomic transactions, sending SOAP messages, Oracle Web Service Manager (OWSM) security policies, among others

If you have a web service implemented on a Weblogic server, it is very easy to access the Web Services Test Client, just access the URL http://host:port/ws_utc of your project. The host must be replaced by the Weblogic server being used and the port must be the one used by your Weblogic (usually port 7001 is used as the default).

Exemplifying

I will show below some screenshots of how the test scenario can be set up. For the example, I used this repository available on Github. After uploading the environment, just access the project URL following the pattern mentioned above, and what will appear will be the screen below:

Image 1 - Endpoints registered in the application

In the screen above we can see the two endpoints created in this project, "GetRhymingWorld" and "Hello". When clicking on the first, we have the screen shown below, listing the received parameters and options for authentication, addressing, among others. For our example, we will only use the function of passing parameter, to check how the API tests work in this scenario.

Image 2 - Parameter of the first endpoint

This application's endpoint was created to receive a word and return its rhymes from the Datamuse website. I took the test searching for the word 'Java'. When clicking on 'Invoke', Weblogic will send a request to the API, bringing the results in xml format.

Below we see the xml that was returned with the English synonyms for the word 'Java'. We can also see that there is some data in JSON, but this is because this is the way that the Datamuse API returns its results. Nothing that a simple stop in the application does not solve.

Image 3 - Endpoint return

It is worth mentioning that there are other applications that bring the same type of functionality, such as SoapUI. The difference is that with this tool you gain a little more agility because it is already a feature implemented in Weblogic, in addition to having one more option for the time when multiple tests are needed.

If you have any suggestions or questions, just send me in the comments or by message!

Desenvolvimento não é apenas sobre código

Danilo Soares Cardoso — Sun, 24 Nov 2019 20:56:18 +0000

Artigo postado originalmente em danilo.dev

Quem trabalha com desenvolvimento geralmente passa por momentos em que se sente frustrado. Isso pode ocorrer porque um determinado programa não funcionou ou, o que acaba sendo pior, com as escolhas que foram feitas na carreira e por não perceber uma solidez no que faz. Quando cito isso, não estou me pautando apenas pela experiência própria, mas sim pela convivência com diversos programadores ao longo desses anos. E aí, como lidar com as frustrações na vida de desenvolvedor?

Antes de tudo, creio que valha ressaltar que este texto não é um canivete suíço que vai valer para todo e qualquer profissional de tecnologia. Assim como um framework JavaScript não vai suprir todas as necessidades de um projeto, um texto não vai ser o remédio para todos os problemas. Minha ideia aqui é compartilhar um pouco do que aprendi ao longo do tempo e mostrar que precisamos, sim, desacelerar às vezes.

Cuide de sua saúde mental

Mais do que ser um excelente desenvolvedor, é muito importante que você esteja bem consigo mesmo. Li dias atrás no Twitter do grande Willian Justen uma thread onde o pessoal falava sobre saúde mental de devs e acabei caindo nesse post dele. Achei uma leitura sensacional porque mostra como a gente precisa dar algumas pausas no dia-a-dia pra simplesmente descansar. Conheço muita gente que passa a semana inteira trabalhando até tarde, vai pra eventos no final de semana, mas não tem um momento de relaxamento, pra conectar consigo.

Seja meditando, lendo um livro ou fazendo uma caminhada mais longa, é essencial desacelerar para manter o ritmo no dia-a-dia. Por mais que pareça uma frase desconexa, ela faz todo o sentido. A gente precisa de momentos de paz pra conseguir relaxar a mente o bastante para não adoecer.

Produtividade não é sinônimo de profissionalismo

Uma métrica que eu usava muito no passado e que vejo ser muito errada era a de que você define o quão bom é um desenvolvedor através da sua produção, ou seja, quanto mais código ou entregas ele faz, melhor ele é. Demorou bastante pra minha ficha cair e perceber que um bom desenvolvedor não é aquele que entrega muito. Quando você começa a aprender uma tecnologia, é natural que queira ter soluções prontas e que mostrem o seu potencial, mas isso não faz de você um bom profissional.

Com o passar dos anos percebi que para ser um bom desenvolvedor, você precisa entender que em alguns momentos sua produção não será a melhor da equipe. Isso pode ocorrer nas horas em que o conhecimento de uma ferramenta ainda está sendo adquirido, quando o projeto é difícil de assimilar ou até mesmo quando algo pessoal te impede de focar 100%.

Nessas horas, é sempre importante ter esses problemas alinhados com seu gestor. Existem metodologias que buscam facilitar essa comunicação, mas se sua empresa não usa tais mecanismos, vá até seu gestor e explique a situação. Afinal, proatividade é algo que faz toda a diferença nas empresas. Quando você mostra para sua gerência que conhece os seus pontos fracos, isso mostra que você sabe onde pode melhorar, o que é algo essencial em times auto gerenciáveis, um item importante de métodos ágeis.

Você não é a Wikipédia

Quando eu era adolescente, ficava abismado com a quantidade de conteúdo que havia na Wikipédia. Não podia usar ela nos trabalhos escolares, mas ainda assim fazia meus olhos brilharem, com tanta informação a poucos cliques. O tempo passou e percebi que, apesar de acumularmos conhecimento durante toda nossa vida, existem limitações nesse processo. No caso de um desenvolvedor, é muito comum que ele queira aprender muito sobre muitas ferramentas diferentes. GraphQL, Flutter, React, Node, Hazelcast, Docker...o que não faltam são áreas e especialidades diferentes para nos interessarmos e irmos atrás.

O que vai ajudar a você se estressar menos é focar em pontos específicos de estudo. Por exemplo, se você trabalha com Spring e Angular e pensa em fazer carreira no seu trabalho, vale a pena estudar isso e se especializar. Agora, se sua pegada é trabalhar com infra-estrutura daqui 5 anos, é nesse caminho que você precisa seguir a partir de agora, e não desistir lá na frente.

Existem dois caras com quem falo muito sobre isso durante a semana que são o Gustavo e o Flor. A gente sempre bate papo sobre tecnologias que estão no ar e o que vale a pena aprender no momento. E foi durante conversas assim que percebi como os assuntos abordados neste texto são importantes de se falar. Acredito que valha muito a pena falar sobre isso com desenvolvedores de sua confiança porque ajuda a perceber no que estamos indo bem e no que podemos melhorar. Não só tecnicamente mas nas soft skills também.

DEV Community: Danilo Soares Cardoso

Testing requests to SOAP Webservices in Weblogic

Exemplifying

Desenvolvimento não é apenas sobre código

Cuide de sua saúde mental

Produtividade não é sinônimo de profissionalismo

Você não é a Wikipédia