Monday, March 20, 2017

SAP + Google: how about Apigee API Management?

SAP and Google have announced a partnership. First impression is that SAP will leverage the Google Cloud Platform as an underpinning for its

As Google has just acquired the API Management solution Apigee and SAP is an OEM customer of Apigee, what impact will this have on SAP's API Management offering?

And 2nd question: will SAP Cloud Integration also become available on Google's cloud platform?

Interesting times.


Tuesday, March 14, 2017

Capturing HTTP requests in an cloud world

While integrating with Salesforce, had an issue getting the authentication right. What is that cloud integration platform actually sending to Salesforce? How to get a look into the message on the wire?

Simple but efficient solution, pick one of the many free HTTP endpoints. Point to the temporary URL, send the message and get all the info on HTTP headers and payload. So trivial and easy.






Monday, February 20, 2017

The legal side of integration

Very interesting news in the press the last couple of days. The Salesforce system of the beverages company Diageo allows a large group of users to access data in back-end systems, including SAP ERP. Because of the named user license model of SAP, British court has ruled that a fee must be paid for each user of the Salesforce system. A little known aspect of integration: legal! Actually, the integration between Salesforce and the on-premise SAP and Oracle systems was handled by SAP PI.

Wednesday, February 15, 2017

Interview by AdeptEvents

Regularly I give public workshops on the topic of Application Integration in Belgium via SAI and in the Netherlands via AdeptEvents. A video interview about my workshop and the topic of application integration has just been released by AdeptEvents. Enjoy!


Saturday, February 11, 2017

IBM Watson Customer Engagement

A few weeks ago, attended a big IBM training event about IBM's e-commerce offering. During the conference, a new brand name was released: "Watson Customer Engagement". My primary interest were the B2B integration solution of IBM, that are part of this suite and fall under the category "Watson Supply Chain".

IBM has an extensive range of products that are part of it's Watson Customer Engagement offering: obviously e-commerce or "Digital Commerce", but also Order Mangement, procurement, digital marketing, customer experience analytics and much more. There is even a specific product to have an overview of all available stock across all warehouses and stores.

My focus was rather on IBM's offerings for B2B integration and Managed File Transfer (MFT). Sterling B2B Integrator is the core product on which the Sterling File Gateway builds further to provide a user-friendly Managed File Transfer solution.

Maybe not well known, but IBM also has a very extensive B2B integration network called the IBM B2B Collaboration Network.

Everyone of the IntegrationDesigners team (IBM integration team of the Cronos group) gets his turn to attend events and conferences. Already had the IBM cloud conference in Madrid in October 2016 and now this conference in Las Vegas, Nevada.

Trip to Las Vegas was quite a hell: snow on the road to Brussels airport, more than an hour wait in the plane before take-off in Brussels, very late arrival in New York because of snow, missed connecting flight, long queue to re-book to another flight, just-in-time to get on the last plane to Las Vegas, long wait in the plane to be de-iced, ... Such 28 hour trip is pretty tiring.

By: Guy

Sunday, November 13, 2016

Remote Service API Design

With the longer weekend (Friday Nov 11 is a public holiday in Belgium, to remember the end of WW I) took some time to watch some sessions from the Devoxx conference that has just finished. The talks are already available on Youtube! Great content: Microservices, Reactive, Netty, Kafka messaging, Docker, ... With this conference almost in my backyard, will have to free up some time next year to attend again myself.

One talk immediately drew my attention: "Effective Service API Design" by Elliott Rusty Harold. I know Elliott an XML guru. Remember being at the speaker's table with him at XML DevCon in London back in 2001 where I presented "Understanding SOAP".

Some thinks I picked up:
  • "Contract first" >> "Documentation first"
  • Start small (MVP Minimum Viable Product, YAGNE You Ain't Gonna Need It)
  • Leverage the URL, not everything 
  • Prefer idempotency
  • Use standards: UTF-8, standard data/date formats, standard decimals with 2 digits 
  • Avoid required data elements
  • Deprecation policy, how long to keep the old API, 2 year notice is good
  • Plan for versioning: easier without schema's but with optional fields
  • No assumption about use of client code/library, developers will often not use those 
  • If you build client code/library, develop it by hand and do not generate it 
  • Authentication and authorization remain a challenge
  • Performance!

Although a good talk, would have hoped for some more specific guidelines.
At the start of the presentation, Elliott clearly makes the difference between the local "library API" (e.g. the JDBC API with the java.sql package) and "Remote API" or "Service API". Great definition by the way: a network service (almost always a server) by which programs communicate with a bundle of funcitonality provided by code owned by somone else, running on their computer (not yours).

Thanks to the Devoxx team and Stephan Janssen to publish this great content for free!

Reactive programming, the old way

Reactive programming is the new hit: applications work with a non-blocking, asynchronous programming model. Use of multi-threading is none or very limited. The reactive program responds to messages or events that come in via callbacks. These messages must be handled as quickly as possible, never blocking themselves while being processed.

Made me think of a fun project I was involved with in 1999 and 2000: "GSL", the Generic Service Layer" at Rabobank. We developed an integration layer (by Gartner defined as a "Super API") based on the message passing product Netweave. And this product was completely based on callbacks and a reactive programming model.

Pre-dating XML and with maximum message buffer size of 32K on CICS, we defined our own message format. The messages had a tree structure in a proprietary, textual format. The GSL API allowed the creation, sending, receiving and parsing messages.

All the main platforms were supported: IBM CICS, Tandem (Guardian), AIX Windows NT and AIX. Communication was supported in all directions. So yes, a COBOL CICS program could invoke an ActiveX component on Windows. Code was written in C (and bit of C++). Most often the IBM mainframe and Tandem would be the actual servers.

An old code snippet from those days. This piece of C code writes a buffer back to a client application.

void loclSend(client_t * pClient, size_t szBuf, char * pBuf)
{
  NWDS_ERRNO      retcode  ;
  NWDS_CALL_BACK  complete ;

  /* write data to client process */
  complete.procedure = loclSendComplete ;
  complete.context   = (NWDS_CONTEXT) pClient ;
  retcode = nwds_ipc_write(pClient->hLocl
                          ,(NWDS_SIZE) szBuf
                          ,(void *)    pBuf
                          ,NULL
                          ,&complete) ;
  if ((retcode == NWDS_PENDING) ||
      (retcode == NWDS_SUCCESSFUL))
    lcTraceHdr('I', 'S', pBuf, szBuf) ;

  if (retcode != NWDS_PENDING)
    loclSleepCallback(&complete,retcode) ;
}

The write of the buffer is executed with ndws_ipc_write. This write could return immediately, whereby NDWS_SUCCESSFUL would be returned. But most often, the return code would be NWDS_PENDING. Then the callback function loclSendComplete would be registered and executed when the write was finished. The complete.procedure element contains a pointer to the loclSendComplete() function.