Pular para o conteúdo principal

Postagem em destaque

BlackTDN :: LeetCode :: Comparando Implementações Harbour e TLPP para o Desafio Longest Palindromic Substring

_Créditos das imagens: ChatGPT_ ### LeetCode :: Comparando Implementações Harbour e TLPP para o Desafio Longest Palindromic Substring Resolver o problema do [Longest Palindromic Substring](https://leetcode.com/problems/longest-palindromic-substring/description/) é um exercício clássico de programação, que desafia desenvolvedores a encontrar a maior substring palindrômica dentro de uma string. Recentemente, exploramos soluções tanto em Harbour quanto em TLPP (Total Language Protheus Programming). Neste artigo, comparamos as implementações nessas duas linguagens, destacando suas semelhanças, diferenças e funcionalidades específicas. #### Implementações em Harbour ##### Versão 5.1 Essa solução utiliza a técnica de expansão a partir do centro do palíndromo. Cada caractere ou par de caracteres consecutivos é considerado um possível "centro". O algoritmo expande em ambas as direções enquanto os caracteres forem iguais, retornando o maior palíndromo encontrado. ##### Versão 5....

WSCERR017 / [HTTPS] Requisição retornou NIL

 

Segundo o TDN, o erro: WSCERR017 pode ser causado pelos seguintes motivos:

WSCERR017 / HTTP[S] Requisição retornou [NIL]

Esta ocorrência de erro é reproduzida, quando da geração de um código-fonte de WebServices 'Client', utilizando o TOTVS | Development Studio. Quando informada uma URL para buscar a definição do serviço (WSDL), utilizando o protocolo HTTP ou HTTPS; e não foi possível buscar o link solicitado, o processamento é abortado com a ocorrência acima.

Dentre as possíveis causas para esta ocorrência, podemos considerar :

  • Sintaxe da URL inválida
  • Servidor inválido, inexistente, ou DNF não disponível
  • Servidor fora do ar

Verifique a URL digitada, e realize a requisição da mesma através de um Web Browser, para certificar-se que a mesma é válida e que a definição WSDL está realmente publicada e acessível sob o link informado.

Mas, o principal motivo, não relatado na documentação, é causado por uma limitação, já conhecida, do sistema referente ao tamanho máximo de uma “String”.

Considerando que os Códigos fontes do “Client WS” são montados a partir de instruções AdvPL é possível que o erro “REAL” apareça no console do server.

Pelo que sei não existe solução definitiva, no Protheus, para este problema.

Uma forma de contornar (solução paliativa) seria: Usando uma outra aplicação que suporte WS (Java, PHP, PS, C#, etc…) crie pequenos WS que encapsulem os métodos do WS principal e utilize-os, no Protheus, para a geração do Client WS.

[]s
иαldσ dj

Comentários

  1. eu preciso gerar o client para o serviço a baixo, porem ele da esse erro.
    https://apps.correios.com.br/SigepMasterJPA/AtendeClienteService/AtendeCliente?wsdl

    será que tem como fazer esse cliente no TDS?

    tentei colocar a MaxStringSize =500 mas nao obtive sucesso.

    ResponderExcluir

Postar um comentário

Postagens mais visitadas