Demasiadas regressões acontecem porque alguém se esquece de fazer CLEAR ou de não fazer CLEAR a uma variável.

Estes são os cenários em que já vi o CLEAR ser usado:

1. Antes de atribuir o valor a uma variável;
2. Antes, durante ou depois de um ciclo (LOOP, DO ou outro), para fazer reset a uma variável auxiliar;
3. No início de uma rotina para iniciar os seus parâmetros;
4. Quando uma tabela interna grande já não é precisa, para libertar memória;
5. Porque é PRECISO fazer CLEAR a uma variável.

Vamos analisar cada um dos cenários:

1. Antes de atribuir o valor a uma variável

Custa a acreditar mas já vi isto várias vezes:

DATA sum TYPE i.
CLEAR sum.
sum = a + b.

É redundante. É inútil. É pateta.

Ou isto:

LOOP AT itbl INTO wa.
  calc = wa-a + wa-b.
  (...)
  CLEAR calc.
ENDLOOP.

Não parece tão pateta como o primeiro exemplo, mas é.

Conclusão: é sempre inútil. Pára de fazer isto.

2. Antes, durante ou depois de um ciclo

Isto é inútil, claro:

LOOP AT itbl INTO wa.
  (...)
  CLEAR wa.
ENDLOOP.

Livra-te desse CLEAR.

Isto já não é inútil:

METHOD report_itbl_a.
  DATA sum TYPE i.
  LOOP AT itbl_a INTO wa.
    CLEAR sum.
    LOOP AT itbl_b INTO wb WHERE a = wa-a.
      sum = sum + wb-value.
    ENDLOOP.
    WRITE: / wa-a, sum.
  ENDLOOP.
ENDMETHOD.

No entanto, este CLEAR também pode ser evitado se encapsularmos o conteúdo do LOOP exterior:

METHOD report_itbl_a.
  LOOP AT itbl_a INTO wa.
    sum = sum_itbl_b( wa-a ).
    WRITE: / wa-a, sum.
  ENDLOOP:
ENDMETHOD.

METHOD sum_itbl_b.
  result = REDUCE #(
    INIT sum = 0
    FOR wa in itbl_b WHERE ( a = a )
    NEXT sum = sum + wa-value ).
ENDMETHOD.

Assim o CLEAR já não é necessário porque a variável auxiliar é local ao método SUM_ITBL_B.

A maior parte dos CLEARs podem ser evitados se o scope das variáveis auxiliares for o menor possível.

3. Para inicializar os parâmetros de uma rotina

Reumindo:

• IMPORTING: Não podes nem deves fazer-lhes CLEAR;
• CHANGING: Se a lógica de negócio o exigir, pode fazer sentido usar o CLEAR;
• RETURNING: Isto é sempre passado por valor por isso começa já limpo, não há por que o limpar mais ainda;
• EXPORTING: Como estes são passados por referência, foi sempre boa práctica usar CLEAR para limpar estes parâmetros logo no início da rotina. Mas o Clean ABAP sugere uma alternativa melhor: passá-los valor.

Conclusão: O único cenário em que o CLEAR pode ser usado é para limpar um parâmetro CHANGING.

4. Quando uma tabela interna grande já não é necessária

Se a RAM for escassa, é boa ideia tentar libertar memória pro-activamente o mais cedo possível. Mas nesse caso o CLEAR não é a melhor opção porque não liberta a memória imediatamente. Em vez disso, deverias usar o FREE.

5. Porque é PRECISO fazer CLEAR a uma variável

Pronto. Este é o único cenário em que usar CLEAR faz todo o sentido: a lógica de negócio precisar de limpar uma variável.

A conclusão é: evita ao máximo usar CLEARs. São das maiores causas de regressões. Principalmente naquele tipo de código horrível com rotinas de milhares de linhas seguidas e dúzias de variáveis globais. Curiosamente, usei um CLEAR há uns dias por esta razão já depois de ter escrito este artigo. E reparei nisso exactamente porque uso o CLEAR mesmo muito raramente (até há uns dias também o usava para limpar parâmetros EXPORTING mas vou deixar de o fazer agora que sei que podem ser passados por valor.

O Abapinho saúda-vos.

O conteúdo Se amas o próximo, evita o CLEAR aparece primeiro em Abapinho.

A legibilidade é muito importante em todo o texto escrito. Talvez com a excepção da poesia concreta.

Na sequência do post anterior, aqui fica um par de regras que minimizam o esforço que alguém tem de fazer para compreender expressões booleanas.

1. Tenta que as condições sejam positivas. É mais fácil entender “eu quero ir” do que “eu não quero ficar”.

2. Se tens mesmo de usar a negativa, prefere IS NOT a NOT IS. embora em português se diga “eu não quero ficar”, em programação é mais simples dizer “eu quero não ficar”.

O Abapinho saúda-vos.

O conteúdo Não sejas do contra aparece primeiro em Abapinho.

Porque haveria de ser difícil lê-las? Só tornaria mais difícil a vida de quem vier a precisar de a entender.

Lá porque uma condição IF é complexa não é por isso que tem de ser complicada.

O Clean ABAP tem algumas sugestões para conseguir isto:

• Considera decompor condições complexas
• Considera extrair condições complexas
• Evita ramos vazios no IF
• Prefere CASE a ELSE IF em múltiplas condições alternativas

Aqui está um exemplo de uma condição IF difícil de ler:

IF price > 1000 AND customer_debt > 10000 AND salesorder_status = '1'.
    " code to block invoice
 ENDIF.

Ok, concedo que não é assim tão difícil, mas serve-nos como exemplo.

Isto seria uma evolução:

IF should_be_blocked( ).
   " code to block invoice
ENDIF.

METHOD should_be_blocked.
  result = COND #(
    WHEN is_expensive( price ) AND
      customer( kunnr ).is_deadbeat( ) AND
      NOT salesorder( vbeln ).is_delivered( ) THEN abap_true
    ELSE abap_false ).
ENDMETHOD.

(...)

Sim, até pode ser um exagero. Mas levei a coisa longe demais de propósito só para exemplificar o que pode ser feito para tornar aquele IF inicial mais simples de ler e entender.

O Abapinho saúda-vos.

O conteúdo As condições IF devem ser simples de entender aparece primeiro em Abapinho.

O ABAP está a permitir fazer coisas cada vez mais interessantes em SQL. A última que descobri foi que agora se pode usar CASEs.

Funciona assim:

SELECT
  CASE
    WHEN temperature <= 5 THEN 'FREEZING'
    WHEN temperature <= 15 THEN 'COLD'
    WHEN temperature <= 25 THEN 'MILD'
    ELSE 'HOT'
  END AS weather
FROM zweather
WHERE date = sy-datum
INTO @DATA(weather_today).

Não só evita código desnecessário como fica mais claro e simples de perceber.

O Abapinho saúda-vos.

O conteúdo SELECT com CASE aparece primeiro em Abapinho.

O meu querido amigo Sérgio Fraga faleceu.

O Abapinho também é dele.
Para sempre.

Obrigado amigo por tudo o que foste.

O conteúdo Já tenho saudades tuas Sérgio! aparece primeiro em Abapinho.

Os RANGEs têm propriedades interessantes.

Por exemplo, estas duas linhas parecem a mesma coisa mas não são:

Marado, né?

Ontem cruzei-me com outro tipo de dupla negação bizarra no qual nunca tinha pensado. Quando usamos um RANGE como critério no WHERE de um SELECT e este está vazio, o critério devolve sempre TRUE. É contra-intuitivo porque o correcto seria dar FALSE (em rigor o valor a comparar não está no RANGE) mas dá imenso jeito que assim seja. O RANGE vazio funciona como um wildcard. Ok.

Mas, e se se usar o NOT assim:

DATA r TYPE RANGE of kunnr.

SELECT * FROM kna1 INTO TABLE @data(t)
WHERE kunnr NOT IN r.

Portanto, o RANGE está vazio e por isso logicamente que qualquer KUNNR não se encontra lá e como tal o NOT IN r deveria dar TRUE. Mas, como o RANGE vazio funciona como wildcard e devolve TRUE quando deveria devolver FALSE,… a negação devolve FALSE quando deveria devolver TRUE. E ainda bem. Acho eu…

O Abapinho saúda-vos.

O conteúdo As duplas negativas dos RANGEs aparece primeiro em Abapinho.

Vamos por partes.

Imagina um cenário em que tens uma tabela de parametrização com vários níveis de detalhe que podem ou não estar definidos:

1. BUKRS (empresa)
2. WERKS (plant)
3. LGORT (depósito)

Quando um dos campos está vazio, é um wildcard, ou seja, é válido para todos os valores.

A configuração da tabela é a seguinte:

Portanto, a primeira linha define o valor por defeito e as outras definem valores de outros cenários mais ou menos específicos.

Já vi código com um SELECT para cada possível combinação, que é a coisa mais estúpida possível porque neste casos já são 8 SELECTs e se amanhã alguém adicionar um quarto campo terá de fazer 16 SELECTs.

O mais comum, que na minha opinião é igualmente lamentável, é presumir que os campos se preenchem a partir da esquerda, o que reduz a lógica a um SELECT por cada campo chave da tabela. Algo assim:

SELECT value INTO result
FROM zparams
WHERE BUKRS = i_bukrs
  AND WERKS = i_werks
  AND LGORT = i_lgort.

IF sy-subrc <> 0.
  SELECT value INTO result
  FROM zparams
  WHERE BUKRS = i_bukrs
    AND WERKS = i_werks.

  IF sy-subrc <> 0.
    SELECT value INTO result
    FROM zparams
    WHERE BUKRS = i_bukrs.
  ENDIF.

ENDIF.

São 3 SELECTs e 2 IFs. É muita coisa.

Até há pouco tempo eu fazia um RANGE para cada campo chave e depois resolvia a coisa com um único SELECT ordenado de forma a que as linhas mais específicas sejam as primeiras:

DATA r_bukrs TYPE RANGE OF bukrs.
DATA r_werks TYPE RANGE OF werks_d.
DATA r_lgort TYPE RANGE OF lgort_d.

IF i_bukrs IS NOT INITIAL.
  r_burks = VALUE #( option = 'EQ' sign = 'I' ( low = i_bukrs ) ).
ENDIF.
IF i_werks IS NOT INITIAL.
  r_werks = VALUE #( option = 'EQ' sign = 'I' ( low = i_werks ) ).
ENDIF.
IF i_lgort IS NOT INITIAL.
  r_lgort = VALUE #( option = 'EQ' sign = 'I' ( low = i_lgort ) ).
ENDIF.

SELECT value INTO result
UP TO 1 ROWS
FROM zparams
WHERE BUKRS IN r_bukrs
  AND WERKS IN r_werks
  AND LGORT IN r_lgort
ORDER BY bukrs DESCENDING werks DESCENDING lgort DESCENDING.
ENDSELECT.

Ainda é muito código e usa 3 variáveis auxiliares mas ao menos a lógica é mais simples de manter: um SELECT e nenhum IF.

Mas recentemente lembrei-me de que é possível simplificar imenso:

SELECT value INTO result
UP TO 1 ROWS
FROM zparams
WHERE BUKRS IN (space, i_bukrs) 
  AND WERKS IN (space, i_werks)
  AND LGORT IN (space, i_lgort)
ORDER BY bukrs DESCENDING werks DESCENDING lgort DESCENDING.
ENDSELECT.

Olé!! Um SELECT, zero IFs, zero variáveis auxiliares.

Obrigado hello-julie pela foto.

O Abapinho saúda-vos.

O conteúdo SELECT WHERE field IN (*, x) aparece primeiro em Abapinho.

Quantas vezes na tua vida de consultor tiveste de lidar com dumps que aconteceram em consequência de um programa tentar inserir duas linhas com a mesma chave numa tabela interna definida com UNIQUE KEY?

Chega.

Desde o século XX que nos habituaram a usar o comando APPEND para inserir numa tabela interna. Mas já há algum tempo que a própria SAP o desaconselha e sugere usar INSERT INTO TABLE ao invés.

E fazem bem porque o APPEND acrescenta uma linha no final da tabela e no caso das SORTED TABLE é muito provável que dê asneira. Já o INSERT INTO TABLE, pelo contrário, adapta-se a todo o tipo de tabelas.

Mas o INSERT INTO TABLE tem outra vantagem: não lança excepções. Em vez disso, devolve um erro na SY-SUBRC caso não tenha conseguido inserir. Claro que este erro tem de ser tratado.

Dito isto, eu não tenho nada contra excepções e a minha forma preferida de inserir entradas numa tabela interna, seja ela qual for, é a nova VALUE #() que lança uma excepção caso hajam chaves repetidas. Ainda assim, seria fantástico se adicionassem a opção DISTINCT ao VALUE pois este tornar-se-ia ainda mais útil.

O Abapinho saúda-vos.

Foto: Jo Zimny

O conteúdo Insere sem excepções em tabelas internas com chave única aparece primeiro em Abapinho.

Em 2012 lamentei que a LISTBOX fosse tão pouco usada. Ensinei a usá-la com elementos de dado standard, que a populam automaticamente. Hoje vou-te ensinar como a podes popular tu próprio se quiseres listar opções que não venham de um elemento de dados.

É fácil. Mas pouco óbvio. Há uma FM standard que a popula a partir de uma tabela interna:

PARAMETERS: p_virus TYPE C AS LISTBOX VISIBLE LENGTH 25.

INITIALIZATION.
  DATA(values) =
    VALUE vrm_values(
      ( key = '1' text = 'COVID-19' )
      ( key = '2' text = 'Bird flu' )
      ( key = '3' text = 'Spanish flu' )
    ).

  CALL FUNCTION 'VRM_SET_VALUES'
    EXPORTING
      id              = 'P_VIRUS'
      values          = values
    EXCEPTIONS
      id_illegal_name = 1
      OTHERS          = 2.

É isto.

Foto: MarianaLeme.

O Abapinho saúda-vos.

O conteúdo Popula manulamente uma LISTBOX aparece primeiro em Abapinho.

Há tantas coisas que se podem fazer nos ecrãs de selecção. Aqui está mais uma: cinco botões na barra de ferramentas.

Para usar estes botões é preciso:

• declarar uma estrutura especial chamada SSCRFIELDS;
• preencher os seus campos FUNCTXT_01 até 05 com os textos dos botões;
• declarar os botões que queremos usar com o comando SELECTION-SCREEN FUNCTION KEY N (em que N é um número de 1 a 5);
• Usar o SSCRFIELDS-UCOMM no AT SELECTION-SCREEN para saber que botão foi empurrado.

Aqui está um programa exemplo:

REPORT zvirus.

TABLES sscrfields.

SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME.
PARAMETERS: p_matnr TYPE matnr.
SELECTION-SCREEN: FUNCTION KEY 1,
                  FUNCTION KEY 2,
                  FUNCTION KEY 3.
SELECTION-SCREEN END OF BLOCK b1.

initialization.
    sscrfields-functxt_01 = 'COVID-19'.
    sscrfields-functxt_02 = 'Bird flu'.
    sscrfields-functxt_03 = 'Spanish flu'.

AT SELECTION-SCREEN.
  CASE sscrfields-ucomm.
    WHEN'FC01'.
      p_matnr = 'SARS-COV-2'.
    WHEN 'FC02'.
      p_matnr = 'H5N1'.
    WHEN 'FC03'.
      p_matnr = 'H1N1'.
  ENDCASE.

E aqui está o resultado:

O Abapinho saúda-vos.

O conteúdo SELECTION-SCREEN FUNCTION KEY N aparece primeiro em Abapinho.

Quando tens de enviar o mesmo email para mais do que um endereço, o mais comum é guardar a lista de endereços numa tabela qualquer e depois adicionar todos os endereços como recipientes.

Mas aprendi recentemente uma forma muito mais bonita para conseguir o mesmo resultado.

O SAP tem uma funcionalidade standard que permite criar listas de distribuição. Através da transacção SO23 crias uma lista de distribuição, dás-lhe um nome, escolhes uma pasta e depois adicionas-lhe tantos recipientes (endereços de email, usernames, etc) quantos quiseres.

Para enviar um email através do BCS para uma lista de distribuição a única diferença em relação ao normal é que para adicionares a lista como recipiente fazes isto:

recipient = cl_distributionlist_bcs=>getu_persistent(
  i_dliname = lv_mlrec
  i_private = space ).
request->add_recipient( recipient ).

O resto é tudo igual.

Foto de doug turetsky.

O Abapinho saúda-vos.

O conteúdo Envia emails para uma lista de distribuição aparece primeiro em Abapinho.

Embora muitos ABAPers ainda se esqueçam disto, quanto menos textos forem fixados no programa mais fácil será traduzi-lo.

Aqui está uma forma simples mas relativamente obscura de alterar os textos para, por exemplo, adicionar-lhes ícones, mantendo-os traduzíveis.

A magia acontece no INITIALIZATION.

PARAMETERS: p_erdat TYPE erdat.

INITIALIZATION.
  %_P_ERDAT_%_APP_%-TEXT = icon_date && %_P_ERDAT_%_APP_%-TEXT.

E aqui está o resultado (nota o ícone do calendário à esquerda do texto):

O ABAP está cheio de truques bizarros como este.

O Abapinho saúda-vos.

O conteúdo Manipula textos de selecção sem os fixar no programa aparece primeiro em Abapinho.

Imagina que chamas um módulo de função por RFC várias vezes seguidas. Se calhar julgas que cada chamada é completamente independente. Mas não é. O grupo de funções fica carregado em memória no sistema remoto e os mesmos dados globais serão reutilizados em todas as chamadas.

Isto não deverá constituir um problema na maior parte dos casos. Mas haverá cenários em que, por uma razão ou outra, o módulo de funções chamado guarda dados em variáveis globais que podem interferir negativamente com as chamadas subsequentes.

Se quiseres garantir que isto não acontece e que tens dados fresquinhos de cada vez que a função é chamada, acrescenta AS SEPARATE UNIT à chamada. Simples.

CALL FUNCTION 'Z_FAZ_MAS_TEM_VARIAVEIS_GLOBAIS'
DESTINATION rfcdest
AS SEPARATE UNIT.

O Abapinho saúda-vos.

O conteúdo Chama função remotas AS SEPARATE UNIT aparece primeiro em Abapinho.

Como é que se há-de traduzir dummy? Fica manequim.

Comecei a trabalhar recentemente num cliente novo e reparei que fazem aqui uma coisa que me agradou. Quando precisam de invocar por RFC módulos de função em outros sistemas SAP, criam localmente um módulo de função com o mesmo nome mas sem código, apenas com um comentário explicando que é uma função remota noutro sistema.

A virtude disto é que assim pode usar-se a ferramenta where-used para descobrir todos os sítios onde é invocada. Só isso. E não é pouco!

Chamemos-lhes funções manequins.

O Abapinho saúda-vos.

O conteúdo Funções manequins aparece primeiro em Abapinho.

Depois de 10 anos a usar o Evernote, este ano comecei a procurar alternativas. No início o Evernote era fantástico. Mas parou no tempo e deixou-se ultrapassar. Entretanto apareceram tantos conceitos novos: jardins digitais, backlinks, Zettelkasten, Evergreen notes, MOCs, etc. E o Evernote lá continua, igual ao que sempre foi, condicionando-nos a tirar notas em vez de criar notas.

Em Julho deste ano tentei migrar para o Notion mas não correu bem. Não só não gostei da experiência como compreendi que, embora o Notion fosse uma evolução em relação ao Evernote (Markdown, backlinks, etc.), não preenchia alguns dos requisitos básicos para mim:

• Não usar a Cloud (ficheiros locais)
• Fácil de fazer copy & paste de outras fontes
• Bom interface (práctico e rápido)
• Não ficar preso a um programa
• Gestão de versões (git)

Então tergiversei. Abandonei o Notion e voltei para o Evernote. Felizmente ainda não tinham divergido muito. Decidi aguardar que aparecesse algo que respondesse a todos os pré-requisitos. Imaginei que o Athens poderia ser uma hipótese.

Até que me cruzei (novamente) com o Obsidian. E foi amor à segunda vista! É que já tinha instalado o Obsidian há uns meses mas não o tinha explorado muito. Além disso ele tem evoluído muito nos últimos meses.

Depois de o explorar e experimentar bastante, compreendi que o Obsidian é fabuloso, responde a tudo o que eu preciso e ainda permite coisas que eu não tinha antecipado. Decidi adoptá-lo.

Mas desta vez não migrei tudo de uma vez do Evernote para o Obsidian. Estou a migrar por partes. E ainda bem, porque isso tem-me permitido ir compreendendo melhor como lidar com cada caso particular.

Estou a usá-lo diariamente há duas semanas e, ao contrário do Notion, o Obsidian é práctico, super rápido e dá muito prazer usar. Penso que é desta. E é grátis! Mas é tão bom que eu decidi pagar os $25. Eles merecem.

Dito isto, há alguns cenários que ainda não entendi como fazer funcionar bem no Obsidian. Esses continuam no Evernote, à espera que eu encontre uma solução ou que o Obsidian passe a permitir MOCs dinâmicos. Não tem mal. Esperarei tranquilamente.

Actualizarei este artigo quando tiver novidades. Até lá, vou continuando alegremente a podar o meu jardim digital no Obsidian.

O Abapinho saúda-vos.

O conteúdo Adeus Evernote, olá Obsidian aparece primeiro em Abapinho.

Sou do tempo em que as notas da SAP se introduziam à mão. Copy paste e rezar para não errar. Granda maluquice.

Lembro-me de um projecto que, por alguma razão que nunca ficou clara, em vez de se fazer upgrade, decidiu-se implementar várias centenas de notas à mão. Imprimiram as notas todas, fizeram num monte gigante com elas e uns 10 consultores passaram um fim-de-semana inteiro a tentar acabar com o monte. Conseguímos. Não faço ideia do que aconteceu a seguir mas de certeza que criámos montes de bugs.

Felizmente entretanto apareceu a transacção SNOTE que tornou o processo automático.

Mas… e se tiveres usado o SNOTE para implementar uma nota e depois te arrependeres?

Embora nem toda a gente o saiba, felizmente o SNOTE também ajuda nisso:

Menu SAP Note > Reset SAP Note Implementation.

Obrigado Sérgio Fraga pela dica.

Obrigado dps pela foto.

O Abapinho saúda-vos.

O conteúdo Desfazer implementação de nota SAP aparece primeiro em Abapinho.

Um dos primeiros artigos do Abapinho foi sobre o Evernote. Ou melhor, foi sobre a importância de tomar notas. Mas nele eu explicava como uso o Evernote para tirar essas notas.

Parece mentira mas passaram 10 anos. 10 anos a tirar notas no Evernote. Infelizmente parece que quem faz o Evernote deve ter parado de tirar notas há muitos anos porque o Evernote pouco evoluiu desde que o adoptei. Aliás, na versão iOS, piorou. Já lá vão 10 anos e ainda não conseguiram sequer (tentar?) implementar uma forma decente para editar tabelas. Burros.

Fiquem lá em 2010 que eu vou seguir em frente.

Já há uns tempos que andava a considerar migrar do Evernote para algo tipo Wiki, idealmente alojado por mim, pois gosto cada vez mais de ser dono dos meus conteúdos (este assunto dava pano para mangas mas como não tem nada a ver com ABAP, o assunto fica aqui de mangas curtas). Mas nunca encontrei nenhuma que fosse tão práctica como o Evernote. Portanto, no caso das minhas notas, o self-hosted vai ter de esperar mais uns tempos.

Principalmente porque entretanto conheci o Notion e o Roam. Por muito interessante que o Roam seja, para já não é uma hipótese porque só tem versão browser e porque é mais caro do que eu estou disposto a pagar por um gestor de notas.

Portanto, adeus Evernote, olá Notion.

Não vou explicar aqui todas as virtudes do Notion porque são muitas. É mais fácil ires ver os vídeos que eles têm no site ou experimentares por ti próprio. Mas, assim em resumo, imagina uma extraordinária orgia entre o Evernote, o Trello, o Wunderlist, o Calendário, o Basecamp, o Google Docs e mais uns sujeitos que por ali iam a passar. Daquele extravagante acto sexual nasceu esta espécie de mutante que, além de te permitir tirar notas, permite-te apresentá-las das mais diversas formas, conforme te for mais conveniente naquele momento. Eu até estava disposto a pagar por isto mas eles têm um plano grátis que dá para partilhar notas com até 5 pessoas, podendo estas editar em simultâneo. Importa tudo automaticamente do Evernote sem espinhas e permite exportar em Mardown.

O Notion não é perfeito. O Notion tem bugs. O Notion é mais lento do que deveria ser. E o Notion ainda não tem pesquisa com OCR. Mas o Notion ainda é um bebé e, a julgar pelos emails que já troquei com o apoio técnico, não parece ter pais ausentes como o Evernote.

Procurei agora no YouTube e encontrei este senhor que também usava o Evernote há 10 anos. Experimentou e trocou e já está fã. Este outro é um daqueles malucos que não consegue almoçar sem tirar uma fotografia à comida. Ficou tão fã que acha que this shit will change your life. Um pouco exagerado, talvez. Mas ok. O que é facto é que o Notion não deixa ninguém indiferente.

Experimenta e partilha a tua experiência. Ah, e se conheceres alguma alternativa melhor, avisa, pois ainda estou a tempo de trocar.

2020-08-22: O Notion funciona bem no meu MacBook Pro de 2013 mas é muito lento no meu laptop de trabalho que é Windows. Está no limite de se tornar insuportável. Se não melhorar… vou ter de reconsiderar o Evernote, mesmo perdendo todas as funcionalidades do Notion. Isto enquanto não encontrar uma Wiki suficientemente decente que os substitua todos.

2020-10-02: Desisti do Notion não só porque é muito lento como porque não me adaptei a ter os parágrafos sempre separados, como se fossem bocados de informação independentes, e ter sempre as ferramentas a aparecerem mesmo quando apenas quero escrever texto corrido. Mas acima de tudo porque o copiar e colar texto e imagens a partir da Internet não funciona bem e imprimi-lo ainda menos. Vou continuar a minha quimera em busca de uma ferramenta que substitua o pré-histórico Evernote. O Roam é de todos o mais interessante mas desagrada-me não ser self-hosted. O Athens parece ser uma imitação do Roam que é open-source e que permite self-hosting mas ainda está em desenvolvimento. O Obsidian também é interessante e é totalmente offline. Claramente as coisas estão a evoluir muito rápido. Para já voltei ao Evernote e vou esperar mais uns tempos até encontrar algo que me satisfaça.

O Abapinho saúda-vos.

O conteúdo Adeus Evernote, olá Notion aparece primeiro em Abapinho.

Antes do 7.40 ter modernizado o ABAP, um lookup a uma tabela obrigava a declarar uma variável auxiliar e a pelo menos 4 linhas de código.

Temos a seguinte tabela interna:

DATA(itbl) = VALUE t_t001( ( bukrs = 'COCA' butxt = 'Coca-cola' )
                            ( bukrs = 'PEPS' butxt = 'Pepsi' ) ).

Antes da 7.40 tinha de ser assim:

DATA wa LIKE LINE OF itbl.
DATA butxt TYPE butxt.
READ TABLE itbl INTO wa WITH KEY bukrs = 'SPRI'.
IF SY-SUBRC = 0.
  butxt = wa-butxt.
ENDIF.

Com o 7.40 a coisa tornou-se muito mais elegante. Mas mesmo assim, se o lookup falhar salta a excepção CX_SY_ITAB_LINE_NOT_FOUND com a qual temos de lidar, o que torna o código feio:

TRY.
    DATA(butxt) = itbl[ bukrs = 'SPRI' ]-butxt.
  CATCH CX_SY_ITAB_LINE_NOT_FOUND.
    CLEAR butxt.
ENDTRY.

Mas agora descobri que podemos recorrer ao VALUE e à sua funcionalidade OPTIONAL para nos ajudar a tornar a coisa muito mais simples:

DATA(butxt) = VALUE #( itbl[ bukrs = 'SPRI' ]-butxt OPTIONAL ).

Mais legível e mais sintético e por isso muito mais bonito e elegante.

O Abapinho saúda-vos.

O conteúdo Lookup em tabela sem ter de lidar com a excepção CX_SY_ITAB_LINE_NOT_FOUND aparece primeiro em Abapinho.

Como é conhecido, o SAP guarda internamente os montantes e variáveis com 2 casas decimais. Quando queremos convertê-los no formato externo costumamos usar o WRITE com a opção CURRENCY. Mas o WRITE escreve numa variável alfa-numérica. E se quisermos escrever numa variável numérica?

Nesse caso podemos usar esta bela função:

DATA amount_internal TYPE wrbtr.
DATA amount_external TYPE bapicurr_d.
CALL FUNCTION 'BAPI_CURRENCY_CONV_TO_EXTERNAL'
  EXPORTING
    currency        = currency
    amount_internal = amount_internal
  IMPORTING
    amount_external = amount_external.

Pronto. Os coreanos e os japoneses já podem ficar descansados.

O Abapinho saúda-vos.

O conteúdo Converter montante para formato externo numérico aparece primeiro em Abapinho.

Lá aprendi mais uma pequena funcionalidade obscura do SAPGui. Como acelerar o corte e costura.

No menu de configuração do SAPGui ligar a opção Cortar e Inserir Rapidamente. Com esta opção ligada, quando seleccionas algum texto, este é imediatamente copiado para o Clipboard. Depois é só usares CTRL-V para o inserires onde quiseres.

É discutível se isto é assim tão útil. Eu não vou usar. Até porque a forma como o “corte e costura” funciona é, para mim, algo que deve ser definido ao nível do sistema operativo e funcionar uniformemente em todo o lado. Não entendo estas frescuras da SAP. Mas enfim. Fica a partilha para quem gostar.

O Abapinho saúda-vos.

O conteúdo Cortar e inserir rapidamente aparece primeiro em Abapinho.